When you don’t have metrics and measured capacity it’s very easy to miss the point when you need to throw away your PoC and introduce changes into architecture, technology, backlog.
Improve accuracy of Product Backlog estimates and prioritize items properly
Don’t avoid grooming meetings and discuss you backlog with stakeholders as much as you can. Make sure that people understand you. And one more thing – you must really want that a certain item/vision/idea would be done.
Fixed scope agile
I believe it is possible, but sales people (or probably even customer) must be ready for that. I refer to this great article where samples and descriptions are provided – Agile + Contracts.
I came to a personal conclusion that you shouldn’t compare these methods. And there is only reason for that. All methods are great! But when human comes into process adoption, everything can be distorted. Use what suits you best.
This time i want to share my thoughts about estimates. You can also read this book to get better insight on this topic – Agile Estimating and Planning by Mike Cohn.
There is one very important thing to keep in mind – estimates of size and duration needs to be separated. It helps to plan releases (schedule) with better prediction.
Very good article about life cycle of product backlog item can be found here.
Following activities from my point of view help to improve product backlog items estimates.
Product Backlog grooming meeting (reference)
It is very useful activity and it helps the Team and Product Owner to prepare for sprint planning meeting better and review/updates estimates of future backlog items. This Team estimation should take place regularly. We have a reserved planned meeting in the middle of each sprint. If changes occur or new product backlog items are available the meeting will take place, if there are no changes the meeting is cancelled to avoid waste of time. So, it depends on the situation and Product Owner together with Scrum Master makes a decision.
Product owner briefly presents product backlog items and the development team asks questions. If the global idea is understood the Team moves towards estimation. Some key points about the estimation techniques for teams.
Estimates are shared
Estimates are not created by a single individual on the team. Agile teams shouldn‘t rely on a single expert estimates, estimates are best derived collaboratively by the team, which includes those who will do the work. There are at least two reasons for that: First, we tend not to know specifically who will perform a task; Second, even if one team member estimates size as N story points other team member can remember some fact (problems, changes or something else) from previous sprints which was forgotten by this team member and estimate might be increased or reduced.
Deriving an Estimate
Analogy – estimates can be made by analogy. The Team can say: „This story is a little bigger than that story“. When estimating by analogy, the estimator compares the story being estimated with one or more other stories. It is much easier to estimate relative size rather than absolute size. Do not mix this approach with comparing to a single baseline; it is about comparing one story with another.
Disaggregation – split large stories or features into smaller and easier-to-estimate pieces.
It helps to improve estimates because of three reasons:
- Planning poker brings together multiple expert opinions to do the estimating
- Dialogue ensures that all opinions are taken into consideration while making an estimate and opinions are justified
- Group discussion helps to pin point important things
After the size of product backlog items is estimated Product Owner can prioritize product backlog items later and re-schedule the release if necessary according the team‘s velocity or take other corrective actions.
Sprint planning and Daily Stand-up meetings
This is another level of agile planning which adds another level of precision. The Teams details their estimates of “groomed” product backlog items. You can read more about sprint planning meeting here.
If sprint planning session or results of the sprint identify that size of selected backlog items is different, Product Owner with the Team can review product backlog and make corrective actions: adjust velocity, change schedule, change scope or other.
The daily plan is the most precise, since each team member express commitments to complete (or make progress on) a task during a day. Tasks estimates are adjusted and reviewed every day by the Team.
Different planning levels
Estimates accuracy is improved due to different levels of planning – the release, the sprint and the current day. Such way of planning helps the Team views the project from different perspectives.
The iteration plan helps completing the highly coordinated work of a cross-functional team within short iteration. And the release plan helps the team to keep focus on more distant goals, since only short-term goals may be inconsistent with the desired long-term result.
Why does estimates accuracy matter at all?
People always want to be correct. They feel uncomfortable when are wrong and this happens due to different reasons: personal responsibility, team image on a company level, loose of trust from product owner/scrum master and so on. Motivation will reduce in general and it might lead to not desired results in a long run. But as i noticed the following thing happens first – inaccuracy will result in the team taking on too little or too much, both of which create inefficient story progress through the work queue. And as the result product owner will not be able to predict releases and what features can be expected.
Scrum Master must make sure that estimates are accurate and track the performance of the team.
Practical guidelines to improve estimates
- Involve the whole team
- Plan at different levels
- Separate estimates of size and duration
- Re-plan often
- Track and communication progress
- Learn and adapt
- Plan features of the right size
- Base estimates and plans on facts
„Planning is everything. Plans are nothing. “
Field Marshal Helmuth Graf von Moltke
Information below is from „Do Better Scrum“ – special tips and insights. You can download it from http://www.scrumalliance.org/ I just want to use it for references in my posts 🙂
This meeting is not mentioned in some of the Scrum literature, but is essential if you
want to achieve a continuous flow of the most valuable done features from your
During every sprint, the product owner convenes one or two meetings where the
Scrum Team and, if required, other stakeholders, meet to size backlog items that have
been added or re-size large items that need to be split into smaller ones for tackling in
the next sprint or two.
Teams need to devote 5-10% of their time during the sprint to preparation for
the next sprint or two. The estimation meeting described above is an
example. Other examples are story-writing and release planning workshops.
This is important to avoid a stop-start effect at the boundary of every sprint.
The other implication, of course is that teams should spend 90-95% of their
time doing the work of the current sprint!