Both developers and board members of companies like agile methodology thanks to the easy implementation of new features in a project and update of the product backlog. Agile helps teams to create a competitive and modern final product, adapting it to all the challenges of the modern market. When a new code is deployed every week or every two weeks, the software development process becomes more flexible and competitive.
The process of estimating user stories from the product backlog or sprint backlog is one of the most contradictory issues in Agile practices. The product owner would certainly prefer backlog estimation in hours since he holds the answer to shareholders who prefer to deal with accurate and clear timeframes of a product or a particular stage.
Scrum helps us to use an iterative approach to software development, which allows adjusting the estimation time after each sprint and changing the order of tasks in the backlog to ensure product release within the deadline.
Break it down: decomposing user stories
After the Scrum team has received the user stories, they are often broken down into smaller tasks. If even after decomposition, the team finds a task too difficult to estimate or too large, another round of decomposition may be needed until the task becomes estimable. Each user story from the product backlog should be estimated prior to development.
Many Agile teams use the INVEST principle for decomposition of user stories. INVEST is an acronym that describes the characteristics of good user stories.
A user story should be:
Independent
Negotiable
Valuable
Estimable
Small
Testable
Independent means that the user story can be developed, tested and delivered even by itself.
Negotiable. A user story is not an explicit contract, but an area encompassing a variety of requirements that need to be discussed.
Valuable. Value is one of the most important elements of the INVEST principle. Each user story must deliver value to the user.
Estimable. A good user story should be estimable.
Small. User stories should be small because they need to be fitted comfortably within iterations.
Testable. In Agile, the entire code is testable, and therefore the story should be testable. If one cannot test a user story, it means that the story is too complicated.
If you’re interested in more, read Why Agile Is Not Only SCRUM
Estimating user stories: challenges
Each task needs to be estimated. The cornerstone of all the problems lies in the estimation methods. After all, the product owner and shareholders prefer estimates in hours. This helps them to better understand:
- When the working prototype of the product will be ready.
- When the new characteristics of the product will be made available to users.
- When the new product will be ready for commercial release.
But developers estimating user stories may encounter problems when estimating in hours. For example, every developer works at his/her own speed, and estimates in hours may differ very much. After all, it is clear that a middle developer spends more time on a task than a senior developer. However, if a middle developer has performed such a task before, then, provided that the senior developer has not encountered such a task before, the middle developer will likely spend lesser time than his senior colleague.
Whenever we talk about estimates, we refer to their accuracy. If an estimate is accurate, it very much helps in further development. But when the estimate is not accurate, the entire development process may be disrupted, which can then lead to failure to meet deadlines.
If your team practices Scrum, you must have seen from your own experience that estimates may differ significantly among different people. In estimation, people tend to rely on their own experience or colleagues’ experience. People also often try to either build a safety net by setting a deadline a little more than needed to make sure that the task is 100% delivered on time or, the other way round, name a shorter deadline in order to draw attention (e.g., the manager’s attention).
Scrum teams that are newly created or that have more than one new member may also experience difficulties during estimation. Sometimes, newcomers try so hard to make a good impression before all their team members to the extent that they underestimate a task. This may subsequently lead to disruption in sprint deadlines.
Till now, even Scrum evangelists still have no consensus on how best to estimate user stories – in story points or in hours. Some Scrum Alliance authors even claim that hours and story points reflect and measure different aspects of the development process. There is also the opinion that new members of a Scrum team may initially have difficulty with estimating user stories in story points since their very conception can be unclear. On the other hand, if the Scrum team is already well established, estimates in story points will help create a well-thought-out sprint backlog and deliver all the tasks in it within deadlines.
Most importantly, the Scrum master and product owner should have an excellent knowledge about the capabilities of their team members to convert estimates into story points to hours so as to present a report to the board of directors.
Determining the worth of a story point
The original purpose of any estimate is to determine the unit of measure, which will subsequently be used to compare all other user stories. While an hour is a more or less a clear unit, story points may seem complicated especially for those who have not handled them before.
The most common approach to determining the essence of story points is that all the Scrum team members agree on which task will be estimated in 1 story point (or 0 story points). This should be a one-piece small task that can no longer be decomposed into smaller tasks. Of course, it may take developers in the team different amounts of time to perform such task, but in general, the task should be recognized as the smallest task in the product backlog.
Also, some teams use 0 story points to determine a task that takes negligible time (for example, fixing a small bug in the layout). In this case, the Scrum team decides on how many microscopic tasks will make up 1 story point.
The next step will be to determine the scale for more complex tasks that take more time. Any number from 1 to 10, or a logarithmic scale or the Fibonacci sequence can be used. The last two are even better because values in them grow exponentially, thereby stimulating the division of large tasks or user stories into smaller ones. Also, for any scale, you need to determine which of its value would be the boundary – a task with such a number of story points must be divided into smaller tasks (it’s typically 16 story points for a logarithmic scale and 13 or 20 story points for the Fibonacci sequence).
The Fibonacci sequence is named after the scientist and mathematician who studied its laws. It is a sequence of numbers 1, 1, 2, 3, 5, 8, 13, 21, 34, 55…, where every number after the first two is the sum of the two preceding ones. The Fibonacci sequence is used to estimate user stories because it demonstrates exponential growth and all the numbers in this sequence differ relatively from each other. Thus, Fibonacci sequence is easy to use for comparison and difficult for counting.
With regards to the principles of estimating tasks in story points, Scrum teams usually take into account the following factors:
– Effort – how many hours are required to complete the task;
– Uncertainty – how clear, how will the task be performed, does any member of the Scrum team have a similar experience before;
– Complexity – whether this task is connected with other tasks in a user story if the task needs some kind of comprehensive solution.
Story points are used to measure the sprint scope by finding the average statistical sum of the estimated story points. For example, a user story that has been estimated at 3 story points is not equal to a simple sum of user stories that were estimated at 2 story points and 1 story point.
Steve Bockman’s estimation method
This is one of the easiest methods of estimating user stories, requirements, or tasks. You only need to create cards with a brief description of all the user stories (or tasks, if the user stories are too extensive) from the product backlog and sprint backlog. The description should be sufficient to ensure that each Scrum team member could understand exactly what kind of a user story is involved.
Then all the cards are collected in a pile. Each team member picks the top card off the pile and places it somewhere on the playing surface:
– If a card is placed on the left of a card that has already been estimated, it means that the user story on this card is relatively less complex than the user story on the already estimated card;
– If a card is placed on the right of a card that has already been estimated, it means that the user story on this card is relatively more complex than the user story on the already estimated card;
– If a card is placed underneath a card that has already been estimated, it means that the user story on this card is of equal complexity to the user story on the already estimated card.
Each member of the Scrum team then explains why he/she placed his/her card exactly on that spot. A member can also skip a move. If all the cards from the pile have been laid out, they can be moved, explaining why this is necessary.
When all have skipped their turn, the game ends.
At the end of the game, the cards can be estimated from the smallest to the highest. Estimates are then assigned in story points.
The main aim of this game is to explain the course of one’s thoughts to other team members and hear the views of others.
Planning poker
The Planning poker (also called Scrum poker) represents a more advanced version of estimating tasks or user stories.
Before you start playing, it is recommended to first decide on a set of values that will be used. Scrum teams usually use the Fibonacci sequence because it allows to clearly see the moment when a user story or task is too large and needs to be decomposed. After agreeing on a set of values, numbers from this set are printed out in the form of a card for each member of the Scrum team. Typically, the largest number in the set of cards is 13 or 20. This number serves as a signal that the user story cannot be estimated in the form in which it is, but needs to be decomposed.
During Planning poker session, each member receives a set of cards. The product owner describes the user story and answers questions from other members of the team. Each member estimates this user story, chooses the appropriate card, and places it face down. At the command of the product owner, all the members show their cards simultaneously. If the values in the cards differ significantly, then the team discusses the user story in more detail and then conducts another round of estimation.
Planning poker is a simple and easy way to obtain estimates of user stories from the sprint backlog or product backlog.
Fruit poker
This is a new upgraded version of planning poker. This game has exactly the same rules as in planning poker. The only difference is that fruits are used instead of numbers. Cherry is used as the smallest task, strawberries as a small task, kiwifruit as a medium task, orange as an above-average task, grapefruit as a big task and watermelon as a large and complex task that requires decomposition. Some Scrum teams also use a card called a “fruit salad” to refer to tasks that are too complex to estimate and require decomposition.
Why do we need Fruit poker?
- This simple technique helps a Scrum team to fully concentrate on task comparison, rather than common estimation by counting.
- This technique is very helpful to newly-created Scrum teams.
- Helps those teams composed of new members who have never worked with Scrum before.
Since planning poker involves the use of numeric values, developers with no Scrum experience may encounter problems when estimating user stories. For example, they may attempt to somehow calculate the “correct” estimate based on the values of the cards of other members of the team or based on previous estimates.
Fruit poker, on the other hand, offers a quick and informal way of comparing tasks. Yes, the developer team may within themselves agree that a “Cherry” task requires from one to three hours approximately and a “Grapefruit” task requires from forty to one hundred hours of work, and thus establish some kind of value for comparisons. And that’s it.
Conclusions
Clear and accurate estimates of time and effort in most cases are not the main purpose of implementing Scrum methodology. They are often a pleasant by-product of such implementation. When estimation of user stories is simple and engaging, the Scrum team has all the chances of obtaining accurate estimates, which the product owner can then translate into hours and working days.
Scrum team members usually determine by themselves how they will estimate user stories. Since engagement is one of the core values of Scrum, the team in most cases will work out the most convenient way of estimating user tasks in practice – whether in story points or in hours, whether they will be obtained via Planning poker or Fruit poker. There is no perfect or universally recommended method of estimating user stories. Each Scrum team may find a method that suits it most.
