Product Backlog Estimation
Purpose of Estimation
Estimation is valuable when it helps you make a significant decision,
Martin Fowler in this post share a few useful examples that highlights the importance of estimation in decision making. You might have faced situations in which you don’t know what to develop between two or more scenarios, you need to coordinate among different teams or features, you need to know the value compared to the cost of developing or not a specific feature, you need to make the trade-offs to respond to changes, e.t.c
In all the above cases a decision must be made and estimating the effort or value e.t.c could give you some answers. However whenever you are thinking of an estimation, it should be clear what information will provide in decision making. If there no information connected with the estimation then most probably the effort on estimation is waste of time.
Another benefit of estimation is to help teams and everyone involved in estimation meetings to get a better understanding of various ways to implement product backlog items, discuss issues related to architecture or technologies e.t.c.
- Estimation is neither good or bad and if for your situation you can work effectively without estimation then you can decide that you do not need estimation.
- If you are going to affect important decisions then do your best and make the “best” estimation you can.
- If you need some kind of estimation then try to connect it with the information that will provide in our decision making
- Estimation are not actual numbers
Practice on Estimation
Assume that you are clothing supplier to a football club and you would like to order football players clothes for the new season.Try to estimate the height of the following players in absolute numbers. After estimating, discuss as a team how easy or difficult is to estimate on absolute numbers while reflecting on real number. Remember that you are about to make a decision and your estimation will have an impact on decision making!
Planning poker is the most common used estimation technique by agile teams. In brief for the poker planning you need a set of poker planning cards (0,1,2,3,5,8,13,20,40,100). The value represents story points if you estimate in story points but it could be ideal days or any other unit that you are using in your estimation (even if is common said that planning poker is unitless). Prior starting you need to set a reference user story so to be able to perform the relative estimation of the other stories. At the beginning the product owner present a story and describe it to the team. Discussion around the story is taking place to better understand what is required from the story. After the story has been fully discussed each team member select a card and all cards revealed at the same time. When all members select the same number then this is team’s estimation. In case there are variations the high and low estimators should especially share their reasons. After the discussion a second round might take place to estimate again considering the new data as an outcome of the discussion. The process is repeated until consensus has been reached.
Assume that your investment company is thinking to make some investments in the countries that are listed in slide below and the value of the investment is closely related to the country area. Ask from your team to make the relative estimation using the poker planning technique. Greece is considered to be the reference country. Discuss and repeat as many cycles is needed as to reach consensus. Remember again that the information is required to make decisions.
Affinity Estimation is a really useful technique when you have to estimate a large number of stories. A step by step guide is described in this post. At the beginning all stories in silent mode need to be ranked in a list from smaller ones to larger ones or in relevance with a reference point. Every member picks one story and add it in a relevant place as she think appropriately. The next member either will add a new story (if agrees with the place where the story has been added) or move an existing story. When all members have made their movements then they discuss those stories that have been moved in order to reach consensus. Product owner is there to make the necessary clarification. The same process applies until all stories have been located in the appropriate place. At the end points are added in every group of stories.
Assume that you would like to run a series of surveys and the value depends on the various cities population as listed below. Use the affinity estimation with your team to estimate the relevant size among the cities. Discuss how easy or difficult was to estimate, how useful you have found the discussions around estimations
- Split your stories!.Decide a threshold that will be a good indication to split the story
- Make use of Spikes to get a better view
- Keep data of previous estimated stories. It will help you a lot!
- Make a list of things that need to be considered when making estimation. The Definition of Done could serve as input!
- Get experts support in estimation if you think it will help your team and nothing else has worked!
- The best estimates are given by those who will do the work and in agile sw development teamw are doing the work! If for some reason you don’t believe that teams is capable to do the estimates then try to resolve the surfaced dysfunction first!
- Estimating is a shared and collaborative activity since every team member could add a her or his own view. Building shared understanding shouldn’t be a well-kept secret about estimation. None of the estimation techniques will work if the people building the software don’t have a shared understanding with one another, and with those envisioned it.
- Re-estimate when necessary.The point of estimation is not to have a correct estimation but to make decisions. Velocity is showing us how far or close we are against our plans and it is a great equalizer!
food for thought…
- Understand why you need to estimate. How the estimation will help you decide?
- There are different ways to estimate. Experiment and find the one that serves best your team/project needs
- The more you progress on your project the more teams’ approaches to estimation evolves