A team that I have coached took up and voluntarily committed to a sprint backlog that was not realistic. Worse, not only it was clear afterwards that it was unrealistic, but they knew already right from the start of the sprint. How come they committed to a sprint backlog while they already knew it was not realistic?
This team started their first sprint while work on the product backlog was still work in progress. They took up a few user stories that were already ready. With only a few user stories ready on the product backlog, estimating story points does not make much sense. Since it is a relative measure one needs more than a few user stories to start estimating story points. In 1 or 2 sprints we’ll have enough user stories to estimate in story points and measure velocity. One could choose not to start with scrum when not enough stories are on the product backlog. In this case there was momentum in the organisation and team to start with scrum and we chose not to postpone but to start. In the second sprint the team committed to a sprint backlog while in their minds they did not want to commit. Of course, not having a velocity did not help. Blaming it all on the lack of having a velocity measurement is too simple. There is more.
Velocity is defined as the total amount of work measured in Story Points that the team delivered in the last sprint. There are some subtleties, e.g. when the team has unfinished user stories. Its main use [ScrumGuide] is two-fold. First, the team uses the last achieved velocity as a measure for the amount of work that they will take up in the next sprint. Second, it is used as an insight to the product owner to help in forecasting what features will be finished at a given date. This helps the product owner in prioritising the backlog. Note: The scrum guide does not explicitly mention velocity. Rather it mentions the ‘team’s past performance’ and that the product owner ‘assesses the progress towards a goal’. In practice many teams use ‘velocity’ for this.
In a scrum planning meeting the sprint backlog is established. With teams I help them build up the sprint backlog by starting with the most important user story and let the product owner explain the story. The team gets to ask questions to clarify the story. Finally, I ask the team whether they can commit to completing this user story for this sprint. If ‘Yes!’ this procedure is repeated for the next user stories until the team will not commit anymore. The limit for this sprint has been reached. The velocity helps as a check that the current sprint backlog is realistic. This is based on the team's result form the past.
There is another important use for the team’s velocity. Not only does it help the team in determining how much work they can finish in the next sprint, but it also guards against the group conforming to committing to a sprint backlog when in fact some or all team members think ‘No!’. This phenomenon is known as ‘Group Conformity’ and was demonstrated in the ‘50s in a series of experiments known as the ‘Asch Experiments’ [BlogChe]. These experiments showed that in a group members tend to conform to the opinion/believes of the group even if they think differently. Instead of going against the group members conform to the group’s answer. E.g. in order to avoid being ridiculed.
Back to the team. What happened in the planning meeting? In the planning as a coach I ask the commitment question after adding each user story. The questions are asked to the team one team member at a time. The first few said ‘Yes!’. Finally all team members said ‘Yes!’. But were they also thinking ‘Yes!’? Probably not. What could be the reason for thinking ‘No!’ and saying ‘Yes!’? Inspired by a colleague [Gro13] I can think of:
- after having discussed the user story with the product owner for 10 min. it may be difficult to say ‘No!’, because this indicates that just 10 min. of group time have been wasted; conforming to the group and saying ‘Yes!’ is easier,
- after a few have said ‘Yes!’ it becomes increasingly less easy to say ‘Yes!’, again conforming to the group is easier,
- for the last members to be asked a ‘No!’ sounds like a ‘veto’ which doesn’t feel nice and (again) conforming to the group is easier.
Using the velocity as a tool to decide that the sprint backlog is full and no more user stories should be taken prevents the line of thinking shown above. Team members do not have to say 'No!', their proven past performance does.
Role of the Scrum Master
How could you help as a scrum master? Stick to the process and use the velocity to guard against group conforming effects. The velocity will tell the group that the limit of what is realistic to pick up in the next sprint has been reached, thereby preventing that the team thinks ‘No!’ but says ‘Yes!’. This will help the team only on the short-term.
Role of the Coach
What is the role of the coach? The team coach should stimulate the exchange of ideas and especially the differences in opinions between team members. This will help team members not to conform to the group. Conforming to the group you would expect to see particularly in groups that have just formed. Here members in the group are reluctant in stating ideas and opinions that are different from the rest of the group. The role of the team coach would be help the team through this fase in group development. This approach will help the team on the long-term.
Besides helping the team to determine the size of the sprint backlog and helping the product owner to prioritise, use of velocity aids the team to prevent committing to a sprint backlog while they actually do not want to commit.
|[ScrumGuide]||Scrum Guide, Ken Schwaber, Jeff Sutherland, 2013, https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf#zoom=100|
|[BlogChe]||The Asch Conformity Experiments, Kendra Cherry, https://psychology.about.com/od/classicpsychologystudies/p/conformity.htm|
|[Gro13]||Group Conformity, Rik de Groot, October 2013, Xebia XKE TED style|