2

I'm a PM for a small development team. We have a mix of large transformation projects and small improvement projects.

We're not good at estimating in man hours (and in fact I'm yet to meet a team of people that can do this consistently in any role).

As a result we've agreed within the team to use story points to estimate complexity, and over the next few sprints we'll figure out what the right amount of story points per sprint looks like.

My question is, how can I guide the rest of the business away from using time as a measure? How do we translate story points to allow them to make priority decisions? What's the best way to represent progress on projects (both inside and outside of a sprint? Points done vs Points remaining? Points per person? Something else?

Improve this question
4
  • More context, please: Who do you want to guide away from using time? Why? What priority decisions do they need to make?
    – BaldEagle
    Nov 12, 2017 at 5:14
  • And ... are you using story points within or outside of an adaptive (agile) process?
    – BaldEagle
    Nov 12, 2017 at 5:27
  • Are "rest of the business" in your org. aware of SCRUM team, their roles such as PO, SM etc. and do they understood why arranging product backlog based on priority will add vale to Project execution? If answer to this is No, then it will be hard for you to guide the rest of the business away from using time as a measure. Hence you may 1st wants to make them aware of SCRUM and its overall theory and why you are using it
    – Ashutosh Deshmukh
    Nov 12, 2017 at 6:25
  • At the moment we give estimates which are never correct, and this leads to dissatisfaction with internal stakeholders. Within the Project Office we're happy with the move to story points, but we won't get the average time per story point for a couple of sprints at least. How do we give updates which add value without talking about time?
    – Mand
    Nov 14, 2017 at 10:26

3 Answers 3

Reset to default
3

The idea is that, once a team has stabilized, there are two things which become more or less constant:

  1. The amount of story points in a sprint
  2. The average amount of time for a story point for the team (not per person).

So if you want to get time estimates/project progress, just use those two. For example, to get remaining time for project, multiply the number of story points left by the amount of time per story point.

One thing you should not do is focus on the amount of time a story point translates into per person. As I mention here, a cross-functional team doesn't mean everyone is equally good at everything. So a front-end developer would have a much higher points-per-time ratio for front-end tasks than back-end tasks. Averaged among the entire team, however, the points-per-time should remain constant regardless of the type of work.

Improve this answer
1
  • This is what I planned, but we won't get there for a couple of sprints at least as this is completely different to everything that the team have done before. I guess it's just a case of battle through until the scenario you describe works.
    – Mand
    Nov 14, 2017 at 10:28
1

Based on my experience, I would translate different story point to a date or time when something is ready for either QA or shipping. When a person is not part of the development team they will have very hard time to understanding story points.

For example, if you have a feature that is estimated at 8 story points inside the team, give your business team an estimate in the range of: "Usually it takes the team 2 weeks to complete this size of a task".

Be the translator between your team and the business team.

Improve this answer
1
  • Are you a timeboxed shop (maybe Scrum-ish)? Probably not, because you're not answering time questions with the end of the sprint.
    – BaldEagle
    Nov 12, 2017 at 5:20
1

I voted up Sarov's post. I'm going to just add some nuance to it. I've found that team estimating, even when you get away from hours, still isn't super accurate. It is great for helping the team figure out how much they can do in the next sprint. It's not so great for determining how long the overall project will work. We are constantly learning, so our estimates are constantly changing. Something that was a 13 this sprint may well be a 5 six sprints from now. It's also really easy to game estimates to give what management wants to see.

For forecasting I've moved to Troy Magennis' Cycle Time model. This takes the average cycle time (time from when work starts to when work is done) and plugs it into sophisticated Monte Carlo simulations to generate high probability date or "work we can get done" forecasts. You can find his open source materials via his website, http://focusedobjective.com/.

Cheers-

Improve this answer
2
  • Thanks Joel, we only want to give good estimates for this and the next sprint. We're trying not to plan too far ahead as priorities change. I'll take a look at the model you highlighted.
    – Mand
    Nov 14, 2017 at 10:29
  • The nice thing about cycle time, is that once you get some consistent cycle time stats, you don't need to worry about the specific work. You'll have data that allows you to say "We can get X stories done in three sprints with 80% confidence" or "We have an 80% confidence of getting all the work done on X date".
    – Joel Bancroft-Connors
    Nov 14, 2017 at 17:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.