I recently had a client ask me about a metric that they started using with their teams. The metric was “stories in progress” for more than 6 days. And after seeing a long list of teams that had multiple stories open longer than 6 days, they wanted to understand why.
Here are some of the the reasons the team offered when asked in an executive update meeting:
- Some stories were harder than they expected
- Some stories had dependencies (assumingly unexpected?)
- Some stories were “vertical slices” and therefore ran longer but were larger and included the front and backend portions of the “user story”.
The reasons were pointing out many deficiencies in the team’s operating model. Measuring if the story is “less or more than 6 days” was just exposing it.
One of the executives was confused – I’m not surprised – with the metric, terminology and asked for clarity on what horizontal slices is vs. vertical sliced stories. It was too much detail and the conversation was “taken offline”
Here is the answer I provided offline:
User Stories, real user stories should ideally have realizable user value among other things. In fact, using the INVEST method as a good way to see if a user story is crafted correctly is recommended.
The “S” in invest is indeed SMALL and a good user story should be small when possible and this is not in complete isolation with the other attributes of a good user story. For example, if you make a user story small but you essentially trim it of “customer value” aspects it isn’t good. You’d be better off making it bigger in this case.
So to set an arbitrary expected “size” of a user story is not a good approach and leads to a tricky metric. It could be useful to see trends, but you should always see cases when larger may be better and vice versa. So perhaps an average or mean story “in progress” number could yield some benefit to see trends and improvement areas for some teams.
Clarifying a little more for the client, I pointed out that the various teams didn’t create a consistent “definition” of a user story. For example, some teams prefer to split their work items by “skillset” or as we call it horizontally. An anti-pattern I strongly discourage. So, there would be backend stories and front end stories worked on separately and frequently within the same sprint (ah they are also not Independent). And when combined and released together (hopefully) finally customer value is achieved.
So in this case, by measuring a team’s “in progress” average per story when one team creates a horizontal story and another does vertical slicing is essentially comparing apples and oranges.
The solution is to define what a user story is and stick to it across the teams. I think you would be hard pressed to find a better method than using INVEST. This will force teams to vertically slice. The size should be small, as small as possible but will obviously vary. The guardrail for me is the Sprint timebox. Can this be achieved within 1 Sprint? If not it needs to be sliced.
Now becomes the challenge, because it may very well be difficult to vertically slice a “larger than a sprint” story. And this is when I recommend different work items than a user story. Create a spike or a technical task to prepare for the user story – could be research, design, prototype, infrastructure… Whatever it is, it’s work that needs to be done to support a future User Story, but it isn’t a user story. It should be distinctive, use a different type in your tool ( in this case it’s Task instead of Story) link it to the user story and now you can get more valuable metrics. In summary, if it can’t follow INVEST, don’t call it a User Story. You aren’t skirting work, you are merely classifying it better.
Work-Agile 