Scrum Practices — The missing guide: Part #2
The guide to the most commonly used and effective practices on top of Scrum. Part 2 of the series.
The Scrum Guide is your best starting place for getting into Scrum. But it leaves many gaps in how specifically to implement a viable Scrum process in order to give you the freedom to do it your own way. The purpose of this series of articles is to complement the Scrum Guide and cover the common building blocks many of us use when implementing Scrum, with helpful tips on what and what not to do.
In part #1 we covered the Sprint and the Product backlogs: https://medium.com/serious-scrum/scrum-practices-the-missing-guide-23c9cb991ca5
In part #2 we’ll cover techniques used to help with planning a realistic Sprint.
Story Points
The Scrum guide requires us to estimate Product Backlog Items (PBIs), but the method of estimation is left entirely up to us. The most popular method of estimation used (and misused) by Scrum teams is Story Points, arguably even more popular than estimating by hours/days. But what are Story Points?
Story Points are a relative measure of estimated effort required to complete a PBI (i.e. get it to “Done”). “Relative” tells us that there is no absolute, universal “truth” as to what the value of a Story Point is, it’s up to the team to define it. Once the team assigns a Story Point value to a specific task, they can assign value to every other task by the relative difficulty, complexity, and clarity. For example, let’s say your team is experienced in setting up a new server, and decide that this kind of effort is assigned the value of 3 Story Points. Now when estimating other tasks, they can ask, compared to setting up a new server, how much more difficult or complex is it? If it’s simpler, then it could be estimated to 1. If it’s more complex, it could be 5. Over time the team should develop an internal dictionary of what’s the ballpark of the effort each Story Point value represents.
This understanding of value should be maintained across all PBIs. i.e. you shouldn’t end up in a situation where 1 Story Point means one thing for User Stories and something else for Epics.
It is important to keep in mind that Story Points represent an estimation, not a promise. When the team makes the estimation they often do not have full knowledge of what the entire work may entail. It is normal to get the estimation wrong. As time goes by the team should hopefully improve at getting the estimation within the ballpark over time, but accuracy isn’t a holy grail here. Imprecision is always to be expected.
Story Points are typically assigned during Refinement (more on how this can be done in the Planning Poker section), and the convention is to use values from the Fibonacci Sequence (i.e.: 1, 2, 3, 5, 8, 13, etc.). The reason is that the higher the estimation is, the less value there is in precision. If a Story Point means a full workday and there is a disagreement in the team whether this PBI is 95 Story points or 98 Story points, how much value is there in a discussion to find out who’s right? In the grand scheme of things, in either case, the story would just be labeled “Extremely expensive”. But suppose the discussion is between 1 Story Point to 3 Story Points. Same difference in size as before, but in this case the difference represents three times the size! Here a discussion is certainly valuable to see where this disagreement comes from.
The Fibonacci Sequence perfectly captures the degradation in the value of precision as the size increases and therefore it’s a useful practice to stick only to Story Point values that belong to the sequence. Some teams use a rounded version of the Fibonacci Sequence (most notably 20 instead of 21), which should work equally well.
Common Story Point Pitfalls
Estimating only the work: Even experienced teams can forget that they’re estimating all work required to get an item to “Done”. Most people think only of the effort they personally would need to put into the item. But getting an item to “Done” is a team effort and the whole effort needs to be encapsulated in the estimation. This includes not only the development effort but also any review, testing, or validation. Everything in the Definition Of Done. It’s a good idea to remind your team about this from time to time.
Equating to time: It’s a fairly common mistake to extrapolate a time estimation from a Story Point estimation. In the end, what we care about is how many hours a certain task will something take. But why then are we using Story Points rather than hours for our estimation? Let’s say your team defines one Story Point as an ideal workday (an “exchange rate” of one Story Point to 8 hours of work). Therefore if we have 4 Full-Time team members working 40 hours a week (totaling in 320 hours for a 2-week sprint), that means we can achieve 40 Story Points per Sprint, right? Almost decisively these kinds of calculations will get you with very inaccurate projections. Putting aside the discussion of why this kind of calculation is flawed, there’s actually nothing to be gained from trying to move from Story Points to hours unless you don’t trust your team and want to micromanage them. If you feel you need to micromanage your team, accurate estimations are the least of your worries. Keep it simple: Stick to Story Points and forget about hours.
Planning Poker
Planning Poker is a common way to perform estimation during refinement. It is a sort of secret voting for the Story Point value of the discussed PBI in a way that encourages conversation and validates that everyone agrees more or less on the expected effort of a PBI. When performing the refinement in the same physical space, teams typically use special Planning Poker cards that include numbers from the Fibonacci Series, with an addition of a zero card (i.e. no effort) and sometimes a question mark (i.e. no idea how much effort or not enough information to estimate) and other cards. When the team meets online people use online Planning Poker tools, holding out fingers in front of the camera, or use the text chat to write down their choice.
Before the voting takes place, the team first goes over the ticket and discusses its details. Once everyone is satisfied that they understand the intent and the way to achieve that intent, each team member picks in secret their estimation for the effort in Story Points. When everyone has made up their mind, they reveal their estimation simultaneously.
Rarely do you see everyone agreeing on the value, and that’s a good thing. The most important point of this exercise is the conversation it generates in order to reach a consensus.
Sometimes you have one or two outliers from the main consensus and it is up to them to convince everyone that their estimation is correct. The larger the deviation, the more interesting and valuable the conversation. For example, if everyone votes 1 and one person votes 2, usually the conversation tends to be very short as the difference in opinions is small. But if everyone votes 1 and someone votes 5, that indicates a deeper disagreement on the effort that would require a more thorough conversation to resolve it. Some teams may do another round of voting after the discussion to make sure the ambiguities are solved.
Common Planning Poker Pitfalls:
The tendency to fit PBIs to Sprints: From my experience working with multiple teams, there seems to be a bias for people to estimate items so that they fit in a Sprint. If 8 Story Points is deemed as the maximum size that fits in your Sprint, estimations for big PIBs will tend to gravitate towards 8. Maximum sized PBI in a Sprint is already a risk, as any unexpected complication can push the effort beyond what can be done in a Sprint, but this tendency to underestimate stories around the limit increases the risk further. You can compensate for this by trying to break down such stories further where possible.
Compromising the vote: Sometimes a Story Point value is already assigned to the PBI before the voting takes place, or somebody says out loud what they think the estimation is going to be. Any type of estimation information available before the voting will skew the votes towards the available information (as most people have an aversion to being an outlier) and reduce the value of the exercise.
Spending too much time: Estimation should be quick! The goal is more about reaching a common understanding based on current information than it is about getting the prediction to be extremely accurate. Most of your time should be spent discussing items, not estimating them.
Velocity
Velocity is a very simple metric of using past Sprints’ performance to help planning the upcoming Sprint. ts ubiquitous use is only rivaled by the ubiquity of its misuse, which is the main reason I’m including it here.
To determine your team’s velocity at a given time, simply sum the amount of Story Points moved to “Done” in the previous sprint. If during the last Sprint you completed User Stories with a total sum of 8 Story Points (for example, two User Stories, one sized 5 and the other sized 3), your velocity that Sprint was 8. Simple as that. Typically teams keep track of their velocity going back several sprints. Keep in mind that the velocity is invalidated when the team changes (people joining or leaving). Tracking the velocity of previous sprints only makes sense for a stable team.
Knowing your velocity will aid you in planning and forecasting: If your last Sprints’ velocities were 18, 22, and 17, you could reasonably expect that the next sprint would not deviate too far from these values. When the team looks at their suggested sprint Backlog during planning they can refer to their velocity to help determine whether the amount of work is expected to be enough or not.
Common Velocity Pitfalls
Using Velocity as a productivity metric: If you recall, Story Points are relative and their value is determined by the team. Therefore, different teams are going to have a different understanding of what effort is represented by a Story Point (even if they start with a shared understanding, the understanding tends to evolve as the teams evolve). Therefore do not make the mistake of comparing different teams’ velocity to evaluate their productivity. If team A’s velocity is around 20 and team B’s velocity is around 10 that does not mean that team A’s productivity is twice as much as team B’s. Each team has their own definition of what a Story Point means. Further, using velocity as a productivity metric can encourage teams to overestimate their stories to have an apparent higher velocity.
Velocity as a binding contract: One thing I see teams do is come up with complex calculations taking in the velocity of previous sprints, the number of working hours available, subtract some constant to account for unexpected work, and come out with a number of Story Points they need to plan for this sprint. These numbers rarely line up with how many Story Points the team was actually able to deliver. Velocity is not a predictive metric — it is a retrospective one. When planning, use velocity as data that aids decisions rather than data that dictates decisions. It gives you an idea of the ballpark of what the team can expect to achieve rather than a prediction. The only thing that should determine how much work the team can confidently do this sprint is, surprise surprise, the Team.
Conclusion
This is all I have for the common practices guide. If you’re missing something, please let me know in the comments. I will be happy to add them or collect them to part #3. I recommend using this guide in combination with the Scrum Guide as the starting point. Once you understand the foundations and purpose of these techniques, you can evolve them and adapt them to your teams’ needs.
