DEV Community

loading...

Discussion on: Why we ditched story points to be more value-oriented

Collapse
eljayadobe profile image
Eljay-Adobe

I suppose how story points are used varies greatly.

My team uses story points as a gauge of effort of a story. Although Fibonacci-esque values are not supposed to represent time, for my team they do roughly correspond to:

  • 1 - a day
  • 2 - 2-3 days
  • 3 - half a sprint (we have 2 week sprints)
  • 5 - a sprint
  • 8 - 2 sprints
  • 13 - 3-4 sprints
  • 21 - half a cycle (we have 9 month cycles)
  • 40 - a cycle
  • 100 - over a cycle

For my project, the team* takes on stories, not individuals. The stories are broken down into tasks. Tasks don't have story points; tasks have a time guesstimate in hours. Tasks are guesstimated by the person taking on the task for the sprint.

Stories are not assigned to people; stories are assigned to teams. (Or rather, each team has its own Product Backlog. Each team has its own Product Owner. Product Backlog Items do sometimes migrate from one team to another, usually due to horse-trading by the Product Owners.)

My project has about a dozen Scrum teams. Story points are not interchangeable between Scrum teams.

We do not use Story Points to calculate velocity. Velocity is something that can be utilized by the Product Owner to gauge how much can get done by when, so if the Product Owner was interested in that kind of forecast it could be done. But in my project's situation, the Story Points is more used by the Product Owner as a weighting factor to balance business value against effort to help in prioritization.

* Unless your Scrum teams have only 1 person per team. At a prior company, our Scrum teams operated in that mode.

We use Jira as our tool. I think it is an okay tool. I'm not aware of a better tool. My biggest gripe is that it commingles the Product Owner's Product Backlog with the Development Team's Sprint Backlog. The Dev Team shouldn't be futzing with the Product Owner's Product Backlog. Likewise, the Product Owner should be futzing with the Dev Team's Sprint Backlog. (The commingling may very well be our fault in how we are using Jira.)

Collapse
javaguirre profile image
Javier Aguirre Author

Thank you for the comment!

My team uses story points as a gauge of effort of a story. Although Fibonacci-esque values are not supposed to represent time, for my team they do roughly correspond to:

We used to do this too! But my main goal ditching story points is product-oriented. What we want to achieve is to focus more on delivery metrics and quality, so our metrics go more in that direction (Codacy health, number of deploys, number of features deployed, etc.)

Stories are not assigned to people; stories are assigned to teams. (Or rather, each team has its own Product Backlog. Each team has its own Product Owner. Product Backlog Items do sometimes migrate from one team to another, usually due to horse-trading by the Product Owners.)

We want to go in this direction, having fully autonomous feature-driven teams. :-)

We do not use Story Points to calculate velocity. Velocity is something that can be utilized by the Product Owner to gauge how much can get done by when, so if the Product Owner was interested in that kind of forecast it could be done. But in my project's situation, the Story Points is more used by the Product Owner as a weighting factor to balance business value against effort to help in prioritization.

I think that makes total sense, we wanted to have less metrics so we can focus on the work and value, and for us estimating wasn't giving us much value, also because even you're experienced, calculating velocity is hard and not a value-driven metric.

We use Jira as our tool. I think it is an okay tool. I'm not aware of a better tool. My biggest gripe is that it commingles the Product Owner's Product Backlog with the Development Team's Sprint Backlog. The Dev Team shouldn't be futzing with the Product Owner's Product Backlog. Likewise, the Product Owner should be futzing with the Dev Team's Sprint Backlog. (The commingling may very well be our fault in how we are using Jira.)

We use Jira too and I have the same impression. :-)

Thank you!