Evaluating Agile User Stories
Both the Agile method and scrum are focused on providing everyone involved in the project a feedback loop and thus allowing team members and the client to have a good estimate of what the team can deliver.
Communication is important so that priorities, the difficulty of tasks and other deliverables are evaluated. Agile and scrum use gamification techniques to make this otherwise tedious tasks a fun and efficient process.
Let's explore estimation of users stories in more detail.
Assessing difficulty of an agile user story
Evaluating the difficulty of user stories of our Sprint is an important activity to do before starting. Doing so has several benefits including :
Compare the difficulty of user stories
Commit only to tasks that we think we can do. For example, let's say a team member is not available full time in the Sprint. He may assign himself stories that are more simple.
Track progress
The burndown chart in scrum can effectively display the complexity points assigned to user stories and show task progress. We will talk about agile charts in a later post, but without estimation, it is not possible to have this great visual information.
Force to anticipate complexity
Estimation of user stories is like a contract between the product owners and the delivery team. You pledge to finish all user stories during the sprint as you participated during sprint planning to evaluate what is hard or simple to do. Indeed, technical works may seem complicated but could be simple, and the reverse could be true as well. The delivery team needs to read the description of the user stories in depth and communicate their concerns if they see any difficulty in completing the task.
Estimate the cost of the added value for the final user
In agile methods, it is important to focus on the final user added value or business value and the technical value is only a way to achieve this goal. So each piece of user value has an associated complexity value that needs to be "paid" to make it real. Knowing the measure of the user value, whether it’s essential, important, not important, is crucial for prioritizing tasks. This is also the same when it comes to the cost to build it (the user stories points). We now know estimating is a good thing and not just an old-fashioned method demanded by an unfriendly project manager.
Choose the right points system
The next factor to consider is which point system to use: estimated hours, linear point system, or the Fibonacci suite points.
The response is up to you as long as you stay consistent since a standard metric is needed to compare different Sprints. However, the next paragraph will explain a popular point system in scrum methods and why it is a good option.
Points vs hours
Estimation in hours or days seems more natural in project management as we can actually track this metric with time tracking app or just by analyzing where we spent time. But the problems with hours or days is that it is not accurate. In real projects, some tasks that seemed simple took way too long to be completed and seemingly complex task were done way ahead of time.
You may feel inefficient if you spend too much time on a task than originally estimated. It is different with points as we cannot directly associate a point with real activity. It similar to using "false money" or using foreign currency in a foreign country we do not know. By removing our reference system, it forces us to get more relaxed about estimation.
Non-linear points vs linear
But why not a linear point system: 1, 2, 3…? Instead, scrum uses a well-known mathematics suite: the Fibonacci suite. It starts slowly then increase rapidly in a similar way to an exponential curve. The first few numbers are closer together and the last ones are farther and more distant.
But why and how to use it
The idea behind this choice is to assume that estimation is only an estimation and it’s more important to differentiate clearly the simple and difficult tasks. For instance, 8 is a medium difficulty task. All numbers under 8 are considered easy tasks. Those over 8 are complex tasks. practically, any number from 1/2 to 100 can be used. A benefit of having high values for complex tasks is to highlight the difficulty, especially for the product owner. It also helps take into account that we often underestimate the real complexity of a task.
How to decide the complexity of user stories
But how to do this vote
You can do it with manually by posting it. Note that people should not know the results of team vote as it would likely influence them.
There are good online tools that allow to do that and they are obligatory if you work with a remote team.
So the scrum master adds all agile users stories of the planned Sprint. He reads the description so everyone is aware of it. Then he will open the voting for these specific user stories. Then we know the vote of each one. If there is no significant difference, then we generally take the user stories as the people voted. There is a pie chart that allows to easily see the vote distribution.
On the contrary, if the votes are not concurrent such as when there are two votes for 5, one for 20, and three for 8. Those that voted for 5 and 20 may be asked to share their views on the matter. They may have missed a point or they maybe they know an element or information that renders the task easier or more complex. If the discussion ended with a reconsideration, the team can vote again and come up with a reasonable estimation.
Thanks to this voting technique, we can take advantage of the collective intelligence of the team, which is very different from the traditional top to bottom estimation. And finally, it is a good opportunity to talk about user stories and exchange point of views.
Go further
User stories, and evaluating complexity is just a part of Agile project management. If you want to know more about it, check those other articles in our learn Agile BIM section.