Caseflow: Discussion: Foxtrot story points

[amprokop]

Let's collect some thoughts about story points here.

A summary of the current approach to story points we're trying out:

• Story points are used only as forward-facing estimation tools (we're not going to look back on a sprint and say "the team only got X points done, something must be wrong")
• Only well-defined development tasks are story pointed, while investigation tasks are not, since most of the time you don't know whether an investigation will take an hour or a day or a week.
• Each dev gets 10-15 story points a sprint, depending on how many investigation tasks that dev has.
• We use 1 (half a day), 2 (a day), 3(a little more than a day), or 5 (2-3 days or less defined features) as values for story points.

What do folks think of this approach? What are the good parts and bad parts? We want to keep this simple and flexible and arrive at a solution that everyone is comfortable with :)

[aroltsch]

I like everything you said, except I think investigation stories should also have points.

[sharonwarner]

Agreed that investigation stories should have points. We're already sort of estimating how much time we think it will take by giving the developer fewer story points. Why not formalize it?

If we do have the investigation story pointed, then if the investigation takes longer than the points allotted, it can be brought up as a blocker, or we can discuss how to continue.

[NickHeiner]

I do not find story points to be helpful and recommend against their use.

For years, my team dutifully poured resources into story points: estimation sessions, allocation planning based on points, retrospective analysis based on points, etc. Then, someone in our eng support group did an analysis and found 0 correlation between story points and time spent on task across the entire company. The moment we heard that, we stopped doing story points, and never looked back.

Instead, we simply focused on making all tickets be consistently sized. For my team, 1 ticket being approximately one day's worth of work felt right. This allowed us to keep some of the things we liked about story points, such as having a sense of the comparative size of two projects. But it was way lower cost than bikeshedding over whether a ticket is a 1- or 2-pointer. It also has the benefit of forcing us to break down tickets into manageable chunks instead of the larger-pointed tickets which could get out of hand.

That said, if you do wish to go down the path of using story points, here are some specific thoughts:

Only well-defined development tasks are story pointed, while investigation tasks are not, since most of the time you don't know whether an investigation will take an hour or a day or a week.

I recommend "timeboxing" investigation tasks. This is helpful because it makes sure everyone is on the same page about how much the team wants to invest in that research. I've worked with some engineers who will go off into a corner and work on "science fair" projects indefinitely if you don't give them a sense of the scope of the investigation.

So, investigation tasks would be story pointed as a way to timebox them. "Please spend 3 points of effort investigating X. After that point, we'll evaluate your findings and decide how to move forward." But the key is that by story-pointing an investigation, we're not saying, "this is how long it should take to complete this work" but "this is how long we want to explore this area".

Each dev gets 10-15 story points a sprint, depending on how many investigation tasks that dev has.

This can be simplified if investigation tasks are pointed as well.

We use 1 (half a day), 2 (a day), 3(a little more than a day), or 5 (2-3 days or less defined features) as values for story points.

The purpose of using an abstract measure like story points is that it's not a fixed measure of wall clock time, so we can analyze a team's velocity in terms of points / sprint. If that is not something we're interested in, we might as well simplify and just use wall clock time directly. ("This is a 1-day ticket.")

[amprokop]

For my team, 1 ticket being approximately one day's worth of work felt right.

@NickHeiner — what about tasks that are less than a day's work? How did you handle that?

The purpose of using an abstract measure like story points is that it's not a fixed measure of wall clock time, so we can analyze a team's velocity in terms of points / sprint. If that is not something we're interested in, we might as well simplify and just use wall clock time directly. ("This is a 1-day ticket.")

Using wall clock time directly sounds great to me! It's not much different than what we're currently doing. How do folks feel about that?

[shanear]

To add to what @NickHeiner said, points are also independent of the person working on it. So a 2 point back-end story may take one person a week (because they are unfamilar with it) and another person 2 hours (because they are a back-end guru like @aroltsch).

When you move to wall clock time, it has to be personalized to the dev working on the story. At that point, each dev can decide for themselves how much they can take on.

[amprokop]

That sounds like an argument for assigning each ticket an estimate only when we assign it to a developer, which is actually what we did last time. So sounds good.

[amprokop]

Looks like the consensus might be —

• Continue estimating when ticket is assigned, so we can make sure it fits everyone's context/background
• Move to wall clock time for features. We could we assign each issue 1/2, 1, 2, or 2+ days (anything bigger should be broken down)
• Assign timeboxes to investigation items. So we'll explicitly say something like — "spend at most 1/2 day on this, then add your findings to the ticket and we'll pick it up later"
• Continue refining requirements to minimize back and forth (this is mostly on me to get better at this)

Thoughts, @aroltsch @sharonwarner @nemodjuric?

[NickHeiner]

For my team, 1 ticket being approximately one day's worth of work felt right.

@NickHeiner — what about tasks that are less than a day's work? How did you handle that?

Those tasks are also single tickets. In practice, there weren't enough of them for that lack of granularity to matter.

[aroltsch]

I personally don't support wall clock time. I estimate user stories based on their complexity. For example, I would give 1 point to a story because I think it is very simple to complete and there is no unknown.

[shanear]

• Everyone agrees on timeboxing investigative tasks
• 1,2,3,5: throw up numbers after every story.
• reassess how it's working in a month.
• approved by Nemo (via Mark)