The team was eager to launch into their first release planning exercise.  Wisely, the Scrum Master and Product Owner (PO) did not hand the team a list of already-written user stories.  They knew that while it would take the team a little more time to identify and write the basics of each story, it would pay off many times over with the understanding and ownership of the stories created by this exercise.

The PO presented the first requirement. “Team, we need to provide the back office system with a summary of the day’s sales.”

A developer on the team eagerly grabbed a sticky note and jotted down the story.

While the developer’s willingness to jump in and start writing a story is exactly what the PO or Scrum Master like to see, what is wrong here?  What should the PO and Scrum Master do in response to this story?

Part of the Product Owner’s job is to make sure the team understands WHO the feature is for, WHAT it is for and WHY it is needed. This is crucial because it allows the team to understand the vision for the feature, who it will benefit, and the value that it provides. This information can spur questions from the team and provide guidance as they weigh various potential solutions. Technical teams can very quickly jump to the HOW without fully understand WHAT they are building or WHY they are building it.

We all know the template for a user story: “As a <type of user> I want <some goal> so that <some reason>”.

Right away we can see that the story does not address who the story is for. As written, the story provides at best a modest sense of the goal, but with verbiage such as “Add task in scheduler to invoke C# application” it is more about the solution that the business goal.

Lastly, one of the most powerful components of a user story is the “so that” clause. This forces the PO to justify the story’s existence. What benefit will it provide?  How will it help achieve the overall vision?  If the PO can’t come up with a “so that” clause, there is a good chance that the story is not needed or is not well-enough understood.

Recognizing this, the Scrum Master jumps in and explains this to the Product Owner and the team members. The PO gives a more thorough explanation of the story, focusing on how it will help the business. The end result:

It may not be perfect yet, but it provides much more meaningful information than the original version.  This story will trigger valuable questions from and conversation with the team and ultimately lead to a better product.

Reflections:

• If the story title is about the technical HOW and not the business WHAT, guide the team in rewriting it so that it reflects the business need or goal and not the technical solution.
• Don’t overlook the “so that” part of the story. It forces the PO and team to justify the story and truly understand it.