Story points only for things that provide business value

This was an idea that recently came up during training. One of the large values of using Scrum is the visibility it can provide to the rest of the business organization – clients, product owners, managers, etc. It helps plainly set out what the team can handle, and identify issues that are preventing features from getting done.

As a team gets it’s velocity defined, it may be beneficial to not assign story points to stories in an iteration related to working on legacy systems, production issues, long-standing (or recurring) bugs/defects, or things that in general derive from various forms of “technical debt”. Many managers (or product owners, etc), especially the more teams they have to track, will usually not take the time to really investigate why a team may be having troubles, and making the issues more obvious (such as a low velocity) may be a way to help clearly signal them there are issues that need to be addressed. After given the “green light” to tackle some technical debt, future iterations would see an increased velocity.

On the other hand, you’d still probably need to story point those “non-business value” stories, because you will still want to track when they’ll be resolved, and to be able to include them in releases. Perhaps you’d run multiple iterations in parallel – one for business value, one for everything else, and assign velocity independently. Of course, that has the overhead of managing two parallel iterations, which might be problematic depending on your Scrum tracking methods.

I think it’s an interesting idea that has some merit, but still has some kinks. I like the principals behind it, just not sure how it’s best to proceed with it.


Matt Honeycutt said...

We're using Pivotal Tracker at InRAD now, and actually won't allow you to assign points to anything that's not a "Feature" story. Bugs, chores, etc, can be created and assigned to an iteration, but they cannot be pointed and do not contribute to your velocity. I actually like this approach for the reasons you listed. To me, velocity tracks how quickly we're moving forward, and fixing bugs, paying technical debt, etc, is more "treading water" than moving forward, at least in terms of obvious business value.

James Kolpack said...

While paying back technical debt isn't a user feature, I would argue they aren't completely devoid of business value. It might be that stories can be created about repaying debt that are phrased in such a way that the business value is emphasized. Instead of "Replace nasty un-DRY code in modules X Y and Z with reusable functionality", "As a stakeholder, I'd like to have a quick turnaround for future feature requests similar to modules X Y and Z".

I just did a google on this topic and this article appeared:

... which has some additional strategies - I noticed they all have an underlying assumption of carefully tracking the accrued technical debt. I can agree with that.

Rob said...

Yeah Kolpack, I agree about paying technical debt having business value - and that's the whole idea. It's more difficult for non-technical people to understand, hence by trying to emphasize the real value by showing the decreased velocity towards new features. I guess a better subject line might be "that provide obvious business value". (I just realized - that's EXACTLY the phrase Matt used. I actually read Kolpack's reply first)

Matt - so how do you plan and estimate the work on non-feature related stories? While there are some bugs, chores, etc that are straight forward and easy to estimate in hours, many times that's not the case (at least, not doing it with any accuracy, hence the creation of story points in the first place).

Matt Honeycutt said...

For larger non-feature tasks, I like James approach of spinning in to a "feature" that provides user value. For example, instead of "add unit tests", you could have "Reduce the number of production bugs (by adding unit tests)".

For smaller tasks and bugs though, I don't think they necessarily need story points. If the number of bugs and debt-related tasks remains fairly consistent over time, and if you address them as close to the point of introduction as possible, your velocity should still provide a reliable estimate of how much new work you will accomplish.

Alex said...

Principals? You mean, principles. Gosh, it's your first language, l2Englishn00b. Oh, and another way for a manager to know there are problems on the team is if Rob is a part of it. Just a rule of thumb.

Designed by Posicionamiento Web | Bloggerized by GosuBlogger