Skip to main content

Story Point Guide Activity

Last post 08:28 pm January 24, 2019 by Carmen Jacobs
6 replies
06:46 pm January 22, 2019

     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?


06:58 pm January 22, 2019

I am a scrum master on two teams.

Are both teams working on the same product?


07:03 pm January 22, 2019

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.


08:54 pm January 22, 2019

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.


09:24 pm January 22, 2019

That is a good point and I will keep an eye out for that. Thank you for the feedback!


06:15 pm January 23, 2019

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.


08:28 pm January 24, 2019

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!


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.