In my experience estimating the size of work is one of the hardest things for an agile team to get their heads around. Teams new to the agile Scrum process may be more used to estimating work in terms of hour, however these estimates are often inaccurate as they are done before any work commences as there are a lot of unknowns.
In agile the whole team ‘relatively’ size the work described in user stories using user story points. Story points have no units of measure, but as a piece of work is completed the user story points may be accrued with the points of other user stories successfully completed in the same iteration or sprint as we call it, the total number of user story points earned in the sprint is known as the velocity; it will usually take a new agile team 3-4 sprints of work before their velocity becomes reliable, but this may then be used to help produce various agile reports that may be shared with stakeholders.
It’s important to get the whole team to estimate as everyone in the team is able to bring a different perspective to the estimation, each user story is also likely to need each role to work on it to ensure it is completed by the end of the sprint. For the user story’s points to count towards the velocity the user story will need to be accepted by the Product Owner.
In addition to sizing the user stories for a sprint or sprint backlog, a team will also need to size the user stories in the product backlog, this work is undertaken during the Backlog Refinement meeting. Once the size of the backlog is known the Product Owner will be able to divide the total number of user story points by the velocity telling them how many sprints worth of work there is and when each increment of business value will be delivered. The Product Owner will then be able to make informed decisions about how work is prioritized and grouped together into releases, trading work of a similar size in and out of scope. This planning may be undertaken in a Story Mapping exercise which will be discussed in my next blog.
There are a number of techniques that may be used to actually do the sizing:
Planning poker is a very effective way of estimating the size of work and one of the most popular. It uses a series of numbers based on the Fibonacci Sequence, so numbers 1, 2, 3, 5, 8, 13 and 21 are allocated to individual stories based on how complex the team think the work will be to undertake. Work sized at 1 may be a very simple to produce while worked sized at 21 or more very complex. As one of the principles of agile is to deliver working software at the end of each sprint a user story must be achievable within that sprint, in our sprints we try and make the user stories achievable in half a sprint or less; if a user story is sized at 21 or more then the team may deem the work to be too big and break it down into smaller user stories.
To size the work each member of the team is given a pack of planning poker cards. Each card has one of the numbers listed above on the front; in addition there will be a ‘0’ to indicate there is no work to do; a ‘?’ will be used by the team when they do not know what’s involved in delivering the user story, or the requirements are unclear and a card with a coffee cup on it will be used when they’ve had enough and need a break!
The Product Owner will present user stories to the team one at a time in prioritized order, reading out the requirements and the acceptance criteria so that the team have a good understanding of what’s needed. The team will then ask the Product Owner questions to further clarify the requirements. When everyone in the team is satisfied they know what’s needed they will then choose a card which represents the relative size of the user story. Each member of the team will present their cards at the same time. I often tell my team that it’s like playing rock, paper, scissors and they need to all present their card at the same time as each of their opinions is valid. Sometimes every one is in agreement and hold up the same card, but more often there is a difference of opinion, in which case the people showing the lowest and highest sized cards are asked to explain their thinking. The team is then asked to re-size based on what they’ve heard. This is repeated until there is common understanding of the requirements. There is also a pack of cards spread out on the table and once the size is agreed the user story is put next to the corresponding sized card.
Sizing in this way is useful as it gives everyone in the team the opportunity to speak with equal weight. The other advantage is if there are big discrepancies in sizing, it may indicate team members may have a different understanding of the requirement, in which case they will need to keep discussing until they have the same understanding. This process can appear slow, but it’s quicker than writing a full specification and it ensures everyone has the same understanding of the requirements.
To get consistency across the sizing of user stories a mature agile team will choose a middle of the range sized card and place it on the table next to the 8; this is essentially used as the benchmark and all other user stories are sized relative to this user story.
For teams new to the process there is often a tendency to convert the user story points to hours of work, don’t do it! This is all about relative sizing, how big one user story is relatively to another. Different agile teams have different scales and therefore comparisons between the size of user stories between teams should not be drawn. I’ve recently set up 3 agile projects to run concurrently, each made up of new team members, about half of each team had agile experience while the others were entirely new to the process. I found that converting the story points to sizes helped with understanding of the process, these were set up as follows:
|= No work
= Extra small
= Extra Large and probably too big for a sprint
New teams may look through the list of user stories with the Product Owner and choose one that they think is a middle sized piece of work compared to the others, this can then be the benchmark. When a team first undertakes this exercise it’s common for them to revisit some of their earlier estimations and re-size them. Over the first few sprints the team will get a sense of the size of each piece of work and the fluctuation in sizing will settle down. I tend to then switch the team over to the numbering system very quickly. Once velocity is known the team will also know how much work they will be able to complete during each sprint.
I’ve also seen this planning technique done using playing cards, where the ace is a 1, the cards 2, 3, 5, 8 are used and the Jack is a 13 and the Queen is a 21. The Joker is used to indicate uncertainty in place off the ‘?’; people can draw a coffee cup on a card, it’s always needed. A sprint planning session is usually 5% of the duration of a sprint; our sprints are 2 weeks long, so planning sessions are usually ½ day.
This method of sizing works in the same way as planning poker, the difference is teams will work with sizes of T-shirts rather than numbers. This is particularly useful for new teams as it helps with the understanding of relative sizing.
The following sizes are used by the team:
The team would still use a ‘0’, ‘?’, and the coffee card just as they would in planning poker.
This is often more simple for a team to understand, but Product Owners still need to produce release plans for stakeholders and calculate the team’s velocity, so working with the Scrum Master, the t-shirt sizes will be converted into points; therefore, as an example:
There are some issues with using this method, different team members may have a different understanding of the sizes, so one person may think a large is 30% bigger than a medium while someone else may consider it to be 50% bigger. It’s a good method to get people started and into thinking about relative sizing, but for effective planning teams should switch over to using the numbering system as quickly as possible.
The size of the product backlog is continually refined throughout the project, the main meeting to do this is in the Backlog Refinement meeting. In a two week sprint this generally takes place in the second week and is often referred to as story time. At this meeting it’s also a good idea for the Product Owner to get an understanding of how large a user story is, but it can be rough in terms of small, medium or large, if the team feel a user story is too large or indeed an epic, then they will ‘refine’ it, i.e. break it down into smaller user stories. The detailed sizing is then undertaken in the Sprint Planning meeting.
The practice of estimating has several benefits; It allows Product Owners to produce release plans and know if teams are on track to deliver against a release plan, helping to de-risk work of uncertain size and complexity, teams will know the rate they burn through work and how much work they can commit to within a sprint and stakeholders will have confidence they know when the prioritized features are going to be delivered. Estimating within each iteration allows Scrum teams to see opportunities for improvements. Estimation is just one tool in the agile process that supports the principles of openness, transparency and producing working software. The very process of estimating adds value, when we estimate the team discuss requirements in more detail and gain a better understanding of what is needed.