12.4 Agile concepts and techniques
12.4.1 Agile estimation
One of the most popular techniques used in agile environments is to estimate the work to be done using a points system. This technique can be used for any type of plan in PRINCE2 (see ‘sprint planning’ in Appendix H). Although the technique is reasonably straightforward and commonly used, many of its advantages are not that obvious and sometimes overlooked.
22.214.171.124 The basics
The principal thinking behind this technique is to start estimating by using ‘relative’ estimates (not ‘actual’ estimates) and to do so by harnessing the knowledge of the whole team in a way that everyone can contribute without being prejudiced by other team members.
The most common form of relative estimation is achieved by giving requirements or user stories a points value that means something relative to another requirement or user story. If painting a wall was given a value of one point and painting a ceiling was given a value of two points, this would mean that painting the ceiling would require twice the effort compared with painting the wall. Importantly, this does not give any indication of how long either task will take, but it does mean that if painting the wall turns out to take 5 days then painting the ceiling should take something in the region of 10 days – assuming that we have made a correct relative estimate.
Creating these relative estimates is carried out as a team, where each team member simultaneously gives their opinion by using pre-numbered playing cards or pieces of paper showing their chosen points value. The reason for using playing cards or similar is to avoid people having their estimates affected or prejudiced by other people’s views. One area that can affect people’s judgement is the tendency for people to put too much emphasis on the first estimate suggested. This is known as ‘anchoring’.
When everyone reveals their points estimates it is important that any differences, small and large, are discussed and the reasoning behind the differences is understood. Then another round of voting takes place, which leads to the team estimates converging towards a collectively agreed point value.
Ultimately, a team can work out how many points they can do in a timebox and can forecast future work throughput, although this does need a degree of stability in the working environment so that like is being compared with like.
126.96.36.199 Further information
There are many variations of numbering systems used and most are based on the Fibonacci sequence of 1, 1, 2, 3, 5, 8, 13, 21, 34, etc. Pre-printed playing cards are commonly used with a sequence of 1, 2, 3, 5, 8, 13, 20, 40 and 100 or similar, possibly with extra cards too.
Therefore, using this points system a requirement estimated at eight points would involve four times the effort compared with a requirement classified as being worth two points.
Another very popular technique is called ‘T-shirt sizing’. This involves classifying each requirement or user story as being either small (S), medium (M), large (L) or extra-large (XL) and so on. Even a simple rating of ‘high, medium or low’ as a guide to effort can still be effective. These systems are deliberately abstract in that they can be carried out without any relative values or ratios. In effect they just say that a medium task is bigger than a small and not as big as a large. Ratios (or values) can be used with these approaches if desired as shown in Table 12.2.
Table 12.2 Using ratios along with T-shirt sizes
The reason why the numbers increase exponentially, and not in a linear manner, is because there is more uncertainty as the size of a task increases.
188.8.131.52 Hints that may prove useful
When starting the estimation exercise, see if the team can agree on a single base story that represents a value of one (or another number if preferred) so that every other story has something relative to refer to from the start.
If a story is estimated at a very large number (e.g. 40 or 100) then it would normally indicate that not enough is known about the story to provide a realistic estimate. Further investigative work is likely to be required to understand more about the story.
Avoid using actual times instead of the points when using this technique. It can cause teams to work less hard or too hard if the estimate is inaccurate, and estimates would need to be based on some form of standard working day, which may be difficult to calculate. Points are arbitrary and therefore reduce the likelihood of this problem and the potential for conflict.
Do not compare your relative estimates with the relative estimates of other teams. Each team has its own individual way of doing this, and the approach may not be the same across teams (e.g. the degree to which they factor in their own risk appetite might vary).
When using playing cards or paper to estimate, do not at any time average out the point scores. It is the debate and interaction between the team members that will result in a greater understanding of the task and therefore produce a more accurate estimate.
When considering the relative effort involved it is best not to think of the actual effort required, as this defeats the purpose of the technique. Ultimately these relative estimates can be converted into actual estimates of time and cost if desired but this may not take place (e.g. a delivery team might try and do as much work as possible (measured in points) in the allotted time period). However, in a project context deadlines will need to be forecast so it may be necessary to go some way in converting the relative estimates into times. Please note that when using the more common agile frameworks in the BAU domain, teams are quite happy dealing with relative estimates in the style of points (or similar) and do not convert them to an actual effort figure such as hours or days.
The concept of team-based estimation is often referred to as ‘the wisdom of crowds’, and focuses on bringing different areas of knowledge and experience together in order to get the best estimate possible. Unusual estimates from certain team members may contain great insight. One of the benefits of this technique is the amount of communication and understanding that the team generates during this exercise.
The points values are usually referred to as story points as they typically relate to a user story and the amount of effort involved to complete it. Another similar term used for this is ‘complexity points’ where estimates are based on complexity. This is not the same as effort, which already factors in the level of complexity and is illustrated in Figure 12.4.