Turning User Stories Into Enabling Specifications

I’ve had a contractor re-building my back deck, and adding a screened porch area. I had a little side-project I wanted done in the garage, so we walked in there so I could describe it.

I told my contractor a story , showing him where my car fits in the garage, where the “extra fridge” sits, how much room there is to walk between my side view mirror and the fridge door handle. How my wife has to walk around my side of the garage to get in the house, and when she’s carrying two arms full of grocery bags, it’s hard to get through.

I told him I don’t know enough about housing construction to know if those 2×6’s were structural supports, whether they could be cut and engineered with a header over the top, and if that would provide enough support for the two stories above. I pointed out where the electrical plug is, and I believe the fridge can plug into the same place, without needing to cut the stud that the plug is on.

When he showed the project to his lead builder he just said “There’s pipes and several walls meet here (points up). Prop this with a jack stand. Cut these two studs (pointing), move them out, supporting the next two, and cut 2×6’s to create a header spanning them.”

All of these parts needed to happen. Sometimes the customer needs to tell their story. This activity alone is useful. I’ve seen customers talk to a Product Owner and the outcome was that no work proceeded; the person realized their need was outdated, or they had a solution to the problem already. Helping the customer say “No” is just as valuable as taking an order. Remember the Agile Principle #10, “the art of maximizing the amount of work not done”.

A Product Owner’s job is to understand the customer’s needs in both the language of the customer, and the language of the developer. Although we often use the terms “Story” or “User Story” as interchangeable with “card”, “PBI” (Product Backlog Item), “Feature”, or “Enhancement”… a true User Story is really just one method of telling the user’s journey from his current need to his successful resolution.

The role of the Product Owner is to translate that into “Enabling Specifications”, a list of discrete work items that the Development Team can immediately understand and begin work on.

Note: “Begin” work. If the Development Team has to ask questions before they can start, the written PBI does not yet allow them to “begin”. This is what’s meant by “Enabling”.

_ The PBI is the gunshot that sets the runner at the block free to race forward. _