Friday, February 27, 2015

Revisiting Normalized Story Points

It has been just over 18 months since I published my most popular blog post to-date: "Normalized Story Points". As of this writing, it has received over 5,400 page views, thanks primarily to the reference it has from Dean Leffingwell's blog post from entitled "More on Normalizing Story Point Estimating".

As an Agile Coach who takes continuous improvement seriously, I have learned much and grown much over the last year and a half. Here are a few of the things I've learned regarding Normalized Story Points.

Know Why You Want Them

I've become a HUGE fan of David Hussman's "Dude's Law". Before you do anything, you need to know WHY you're doing it, not just HOW to do it.

The purpose of Normalized Story Pointing is to enable high-level estimation of work for a SAFe Release Train comprised of closely aligned teams, any one of which may pull a Feature off the Program Backlog for implementation. Normalized Story Points should not be used for:
  1. Comparing teams against each other
  2. Forcing teams to use the same story point size (so that "1 Story Point" means exactly the same thing to everyone forever and ever amen)
  3. Defining "Story Point" to mean "Ideal Man-Day"
  4. Any punitive purpose
If you don't know why you're using Normalized Story Points, don't use them. If your intended use of Normalized Story Points violates the mindset established by the Agile Manifesto, don't use them (although, if this is the case then you probably won't realize it unless someone points it out to you).

Beware the Ideal Man-Day

The 4-step process for getting started with Normalized Story Points involves using time as a reference. This works well because you're using a very small story, one with very little complexity, which means the primary factor for determining "bigness" is lapsed time. That being said, I've found that teams that start with this approach have a very, very difficult time recovering from the mindset of "1 point == 1 ideal man-day". This is bad for reasons.

This also leads to teams always using days of availability to forecast velocity rather than taking a rolling average velocity or "yesterday's weather" as an indicator of what they're likely to deliver. Data trumps theory; the approach to get started is based on theory, while average velocity is data.

Individuals and Interactions over Processes and Tools

Processes and tools exist to enhance and enable interactions between individuals, not replace them. As I've explained in a previous post, the process of Agile estimation is beneficial primarily because of the conversation that it fosters. It's a well-formed game that drives a shared mental model of the work for the entire team.

I've found that teams that use Normalized Story Points may skimp on the conversation, especially if one team ends up with work that another team has already estimated (after all, we all share the same definition of story point, right?). This was never the intent behind Normalized Story Points, but that doesn't mean it doesn't happen.

Beware the Recipe Trap

David Hussman explained that he uses "Dude's Law" to help teams avoid what he calls the "Recipe Trap" - doing something because that's what the recipe says to do, without understanding what the intended benefits are. When it comes to Normalized Story Points, the recipe trap is very real and very dangerous. If you use it, be very careful about how you explain and implement it with your teams. If your teams can't all pull from a common backlog; if you're going to use them to run punitive metrics; if you want to streamline your process by reducing meaningful conversation; or if you're looking to use it because that's what SAFe says to do, I plead with you to reconsider.

TL;DR: Normalized Story Points can be a useful tool for your organization, but it's not a one-size-fits-all solution. 

Tuesday, February 17, 2015

Tell Me Why, not How

If you're familiar with the concept of User Stories then you've likely been exposed to the concept of a User Story "script". One of the most common scripts goes something like:
As a <who> I want <what> So that <why>
As a <who> I want <what> So that <why>

Looks simple enough, right? The problem is that most people who grew up in a non-Agile environment are not used to articulating the "why" in their requirements. They are used to capturing what it is that needs to built and how. Consequently, that's what usually end up making it into our stories, causing them to look like:
As a <who> I want <how> So that <what>
As a <who> I want <how> So that <what>

What's the difference? Let's look at an example.

Old Habits Die Hard

It's not uncommon to see a story that reads like, "As an administrator I want unique group IDs for tickets so that I can easily group tickets." On the surface it looks like a good user story. What's the "what"? The author would argue that it's "unique group IDs for tickets", but that's not the need. The need is to "easily group tickets". The author is trying to dictate how to meet that need in the user story. Those familiar with the INVEST model for user stories will recognize that this violates the "N" - Negotiable.

So we need to move the "what" into its place and establish a proper "why", which means we need to have a conversation. What valuable outcome is enabled by being able to group tickets together? Do you want static or dynamic grouping? Are the groups established by pre-established rules, or is the intent for users to group tickets however they like? Once we have our answers, we may end up with a better user story, something like, "As an administrator I want to easily group tickets so that I can sort and filter to easily find tickets of interest for a given task".

Why? Why?! WHY?!?

What have we gained by phrasing the story this way? A couple of things (at least). First, we have context for the story that will enable the team of professional problem-solvers to create the best solution for the problem within the bounds of the NFRs (Non-Functional Requirements) and FSRA (Future State Reference Architecture).

The second benefit is that we can better decompose the story. With the original wording, we would likely decompose the work into the layers of the system - creating a grouping cross-reference table structure first, then the business logic and virtual object code to associate tickets to groups, and finally the user interface layer for the administrator to actually use this functionality.

With the revised wording, we can leverage the advice from Agile Learning Labs at and split our story into smaller stories that are vertical slices through the entire system. This enables us to deliver value sooner and test our architecture as it's being built instead of all at the end.

Living in Reality

This is the most common anti-pattern that I've seen in the real world of user stories. What anti-patterns have you seen? What advice do you have for overcoming user story anti-patterns? Is this even really an anti-pattern?