From Tasks to Stories with Value

I’m almost at the end of the January Practical Product Owner workshop. One of the participants has a problem I’ve seen before. They have a backlog of work, and it’s all tasks. Not a story in sight.

I understand how that happens. Here are some ways I’ve seen the tasks-not-stories problem occur:

  • The technical people see the work they want to accomplish. They create a list of tasks to get there: design database, create infrastructure, fix these typos in the UI, and more.
  • Or, someone (such as an architect) is in charge of breaking down work, not team members. That person creates tasks.
  • Marketing or sales (or someone not in the product development team) says something like this: “I want a drop-down menu,” or a radio button or another report. They don’t remember to explain who the value is for, or why they want that value. Pretty soon, the idea of value is gone altogether, and only tasks remain.
  • Teams start to create stories, and the stories are so large, they create tasks to cover the stories. Pretty soon, they stop creating stories at all. They only create tasks.

Here’s a gotcha: When teams measure story points as opposed to features, they often feel pressure from management to do more points. (See Who’s Playing Agile Schedule Games?)

Your customers don’t buy points. They buy completed features.

Something clicked for the participant last week. He saw the feature chart, which explains how scope expands during the project and what the team(s) delivers.

This chart shows the features complete, added, and remaining to do. Because it measures features—what customers buy and use—there’s no confusion about work done or not done. Plenty of work might be done. But, if the work doesn’t add to a feature, the work is inventory (or possibly waste).

Here’s one value of this chart: Until tasks add up to features, you don’t count them.

My participant couldn’t articulate the problems before. The chart helped him see and discuss:

  • Tasks—by themselves—might not add up to a feature. He wants features.
  • When he counts features, he can describe what’s in a feature set—a collection of features that you might call an epic or a theme.
  • He can explain why he wants just this small feature, and not necessarily all of a feature set for now.

The chart helped him see how to separate stories and count them. He is moving from tasks and technical stories to features, real user stories.

I use this chart with cumulative flow diagrams and the product backlog burnup chart to see where our work is and how much progress we make over time for a given feature set.

I recommend you build and count features (stories). The smaller you can make a story, the faster you can get feedback and see the value in it.

If you’re interested in this workshop, I have just announced the May 2017 dates. See Practical Product Owner Workshop: Deliver What Your Customers Value and Need.

Tags: , ,
Previous/Next Posts
« »

Submit a Comment

Your email address will not be published. Required fields are marked *