Agile methodologies are based on relative estimating. It is a fundamental element of Scrum which increases accuracy and predictability of projects cost and timeline. If you adopt Scrum, you really should estimate in Story Points. However, if you give up on some Scrum rules, Story Points will do a lot of harm. See when you should not even try using Story Points.
Story Points in Scrum
A general concept in estimating user stories in Scrum is to do that using relative measures like T-shirt sizes (XS, S, M, L, XL), custom names (small, medium, large). The key is "relative" word. It means that we should always try to compare user stories to each other and then decide what estimates assign to them. An important difference between such approach and the traditional way known from Waterfall is forgetting about time units (hours, days, weeks).
In Scrum we are aware and we accept the fact that we are bad at predicting exact duration of a project or an activity so we focus on comparing activities to each other. That is much easier task to do. For example, we do not know how long it will take to implement a user registration page in a web application, but we know it is a bigger task than creating a simple login screen.
Usually, team rarely use T-shirt sizes. Much more practical are measures based on numbers like Story Points. They are usually integers from a modified Fibonacci numbers but those are technical details not important for this topic. Integers works well because we may do some calculations on them, draw charts and so on. However, even though they are numbers, they still are relative estimates. When a user story is estimated to 3, it does not mean it will take 3 hours or 3 days to implement. It just means that it is 3 times bigger than a task that is estimated to 1.
Story Points have many advantages. Junior and senior team members will give similar estimates. Underestimating and overestimating is not such a problem compared to using time units. Predicting the expected date of the end of the project is based on the history and statistics not on wishful thinking. Benefits of using relative estimates are so important that they are an necessary element of Scrum. Unfortunately, many teams implement Scrum only partially and some of those shortcuts completely ruin the sense of using Story Points. See what are those dangerous shortcuts.
1. Unstable teams
A Scrum Team should be constant. If we decide to have 5 team member, there should be 5 of them working during the whole project from the beginning to the end. Then the velocity has a chance to stabilize and show a real speed of closing User Stories which is necessary to predict the date of finishing the project.
Of course, team member go on vacations, sometimes people quit and are replaced by others. Obviously that negatively affects predictability but we can deal with that if the level of such changes is reasonable. The real problem starts when the project is a revolving-door and additionally individual team members are randomly pulled out to side projects.
2. Distractions
Even if the team size is stable, it does not mean that velocity is predictable. Some team member might be distracted by other activities that slows them down like questions from other teams, technical problems, being pulled out to do something else.
Generally, that is fine if such distractions are on the same level each Sprint. The issue starts when one Sprint there are no distractions but another Sprint team members have only a half of the time for working on User Stories. It cause team velocity to fluctuate which cause problems in planning.
3. User stories not finished in a Sprint
One of the Scrum rules is to include only finished User Stories to the completed Story Points bucket. It means that if the team finished Sprint with:
- Finished User Story A estimated to 3 Story Points.
- Finished User Story B estimated to 3 Story Points.
- Unfinished User Story C estimated to 5 Story Points.
then we assume that only 3+3=6 Story Points were achieved in that Sprint. Unfinished User Stories are not the team's achievement so the completed Sprint is not rewarded by the remaining 5 Story Points from the User Story C.
Because of that, such unfinished User Story C becomes a problem because it reduced team achievement in one Sprint but increases it in another one. And again - velocity fluctuation is not good. A solution is to fight with unfinished User Stories:
- Split work to smaller parts so they can be completed separately.
- Share a big User Story by two or more team member to make sure it is completed in one Sprint.
- Start working on a big User Story first in a Sprint if priorities allow for that.
4. Changing Sprint scope during the Sprint
Another element that can ruin the sense of using Story Points is changing Sprint's scope. It usually means that during a Sprint new User Stories come and have higher priority than the User Stories the team planned for.
That is not the only possibility. Some teams have to deal with changing scope of User Stories they have already started to work on. Such case is even worse because those User Stories have already been estimated based on a different scope.
5. Estimating fixes
6. Many teams working on a single User Story
A different problem occurs when the team has User Stories that often require engaging other teams. That is not a big deal if other teams are fast and predictable. Unfortunately, delegated elements may get delayed to the next Sprint which cause unfinished User Stories. And that leads to fluctuating team velocity.
Can I use Story Points or not?
Well, look at the above points and see if you can avoid them. Some of them (estimating fixes) are relatively easy to change, but others might be fundamentally built into your organization (like unstable teams). I would suggest eliminating them before you start using Story Points. Otherwise, you will end up with putting a lot of effort in the Man Days to Story Points migration without having benefits of it.
Read also:
