Story Point Guide Activity
I am a scrum master on two teams. We use Fibonacci numbers for pointing at my company. Recently I noticed there was a lot of tension between two members of the team when trying to point a story, I was getting the sense that they were both in agreement about the effort of work, but had assigned different 'points' to that effort.
I did an activity where I sat the whole team down and I asked them to describe what a 1 point story looks like to them, then when they were all in agreement I wrote it down. I did the same for all points up to 21 points. I then sent it to all of them, during this process we discovered that there was some misunderstandings and miscommunications. I told them to use the guide only as that, not as law and that it was only for this team - that other teams would have a different experience. The team has had much healthier discussions around pointing since then, and thus I found this activity to be very successful.
However, I was curious if this is a proper practice or if a more seasoned scrum practitioner would advise against it?
I am a scrum master on two teams.
Are both teams working on the same product?
No, but the activity was only done with one of the teams present. The other team has also done this activity, but only with those team members. Sorry, that was somewhat superfluous information.
It sounds as though you have made a very good job of facilitating a team consensus in both instances.
Bear in mind, however, that situations like this also present an opportunity to coach teams regarding the optimal liquidity of work on the board. I’m not suggesting there’s any reason to suspect a problem with liquidity at this stage, but it may be something to keep an eye on.
As an extreme example, if team members were to agree on the size of 1 point, but this scheme meant a projected capacity of only 5 points in a Sprint, then their work would probably be too illiquid. Transparency over WIP and Sprint control might then be poor. Excess liquidity, on the other hand, can create further inflationary pressures and cause work to be devalued.
That is a good point and I will keep an eye out for that. Thank you for the feedback!
I like your approach and, quite honestly, may steal it. Great idea!
I have said on this forum many times that I have mixed feelings about Story Points and am perfectly willing to use other means if the team can agree and understand it better. For teams that have difficulty understanding/agreeing on Story Points, I find that using T-shirt sizing helps them get a better understanding initially. I have also used Simple/Usual/Complex/Insane as a scale because sometimes Developers can agree on that better. Don't feel like Story Points are your only option. The Scrum Guide just says to provide estimates. It doesn't say what form those estimates have to be. If your teams are struggling, explain the purpose and benefit of estimating and let them come up with something that can be used.
But what about tracking Velocity is we aren't using Story Points?
What about it? Velocity is not the only metric you can use for indicating team's performance. In my opinion it is actually one of the least effect when used alone since it is using a leading indicator that is based on educated guesses. But using it in conjunction with a trailing indicator (throughput or cycle time for example) can be extremely useful. And if you don't use Story Points, you can still get a Velocity. It would be something similar to "we successfully accomplish 2 Simple, 3 Complex in a sprint and always refine Insane to smaller scale." Maybe not as easy to track but just as effective if the scale is clearly understood by the entire Scrum Team. Notice I did not say Development Team. While they are the ones that provide the estimates, the entire Scrum Team needs to be able to understand them.
Thank you Daniel! It was a fun activity and does help on a team building front. That being said, I like what you are saying about alternative ways of pointing. Currently story points are very ingrained in the way our office functions, but I may bring up the idea of trying alternative methods with some teams. That velocity issue was what was stopping us before, but as you say there are other things we can look at. I will look into that a bit further and may bring it up during our Scrum Huddle. Thank you for the suggestion!