written by gunther gerlach-2011
This is a list of the most common mistakes that I have seen again and again along my career in small and large corporations in their intention of implement Agile as the primary development process. I hope while you are reading this, help you to understand what is the logic behind every single practice and try to adapt (shape) to fit into your environment. Remember, the goal is not just follow the best practices but to achieve the goals behind each one.
Read more…
Daily Scrums
Gunther Gerlach
Every time a project is initiated there is no understanding, time-consuming effort to write down all foreseeable tasks or requirements. Usually, a project writes down what is obvious, which is almost always more than enough for a first sprint. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers.
Gunther Gerlach
written by gunther gerlach-2009
Obviously the daily stand-up (or daily scrum) is a good form of status reporting. It’s great for people with a close interest in the project who can spare the time to get to the scrum. But it’s really no good for other stakeholders that can’t get to the scrum each day, either because they are interested in less detail, or because they have an interest in many projects and can’t be at all the scrums.
Gunther Gerlach
written by gunther gerlach-2009
The Product Backlog, in its simplest form, is a list of things that people want to be done to the product, in priority order. Anyone can add anything to the Product Backlog. Anyone. The agile Scrum process, and agile development principles generally, are collaborative and inclusive. There is no longer any need to say no.
The Product Backlog can contain anything. Anything relating to the product that is. Bugs. Enhancements. Whole projects. Issues. Risks. Anything. Having said that, items on the Product Backlog should ideally be expressed in business terms that are of some value to the user (or customer, or business). Not as technical tasks.
Gunther Gerlach
written by gunther gerlach-2009
There are many approaches for the estimation of a project. Some people will tell you to use the estimation based on story points from Fibonacci numbering system, however this approach only work when features are similar enough to keep a project velocity chart (average project velocity per sprint) in your project but, we all know that this is impossible, some features will need less than a hour of development and other sometimes two days. I am not saying that this methodology is not good, I am just saying that is perfect to get your project velocity chart from the project but if you really want an estimate to get the cost and scope from your project you need the estimate in a period of time, usually days of work.
Gunther Gerlach
written by gunther gerlach-2009
Define your Sprint duration: A Sprint is a key when agile scrum process is implemented in SDLC. The Sprint defines the amount of time where a team will release a feature or list of features from a giving sprint backlog. This is an important decision. Scrum suggests 30 days, but they could a week if you estimate that will improve your team efficiency. The optimum Sprint duration depends on many factors. I suggest going back to your team and analyzing the perfect duration to be able of releasing a piece of software. I suggest 14 days, plus a planning day for your team and Stake Holders to create the product backlog prioritize requirements form different teams and, analyze the product burn chart. This will leave 2 weeks of intensive work and also, two Sprints a month.
Gunther Gerlach
written by gunther gerlach-2011
