Estimating Agile Tasks for Scrum Masters
In Scrum, a list of user stories is produced and put together to form a product backlog, and each of these user stories will need to be estimated to work out how many of these stories can be worked on during a given iteration. One of the responsibilities of the Scrum Master is to act as the facilitator in the estimation of the size of each piece of work.
The Use of Story Points
Story point estimation is different from the traditional approach of sizing a piece of work based on the number of hours it will take. Instead, the estimate is derived from the complexity of the functionality being produced, and the figure assigned is based on the relative size and difficulty when compared to other user stories. The reason for this is that there are many variables that could have an impact on the amount of time that a piece of work takes to complete, such as the level of experience of the developer.
The How and Why of Story Points
Story points are important because they give a clearer picture of the size and complexity of a piece of work than the estimation of time required that is used in a waterfall lifecycle. They help the Scrum Master to work out the velocity (the number of story points that can be delivered in a single iteration) of the team. Using story points gives the Scrum Master a tangible representation of what they are dealing with. It also allows them to gauge how things are progressing when updates are given by each team member during the daily stand-up, and to keep a close eye on any of the more complex stories in order to resolve any issues early on.
There are a number of estimation techniques that a Scrum Master can use to assist the team in sizing each story.
The most popular technique is planning poker. This approach involves handing out a set of cards, usually containing a series of Fibonacci numbers, to each team member. The Product Owner then takes each story in turn and describes it in as much detail as possible. Following this, each team member picks the card which they think is the correct size for that particular story and places the card face down in front of them. When everyone has selected their card, they are turned face up to see what the scoring is. If there is a wide variation in scoring, the lowest scorer and the highest scorer are normally asked to give their reasons, and then a re-score is carried out. The Scrum Master then assists with taking the average and marks it down as being the size of the story before moving on to the next item on the list.
This estimation approach can be used when the team seems to be spending too much time trying to get to a very exact number of story points, possibly because some team members are equating this with the number of hours required to complete the work. When using t-shirt sizing, estimates are selected from a range of extra-small, small, medium, large, extra-large, or double extra-large. While this technique can help in situations where people are becoming too analytical and getting bogged down in the details, it does require additional effort on the Scrum Master’s part, as he/she will then need to assist with translating the t-shirt sizes into the number of story points at a later stage when the planning session is over. It tends to be more common to use this technique when people are relatively new to agile, or when a team has been newly formed. Over time, as the team gels together, it would be more appropriate to move to a somewhat more sophisticated technique like planning poker.