Getting DEEP with your Backlog part 1

Product Owners need to get DEEP.

The hardest job in the technology world is the job of product owner.  At my firm and others, the product owner is an afterthought to an agile transformation.  They are usually a business analyst or a mid-level employee working in the department needing software and then they have to spend half their time doing their full time job and then the other half writing user stories and trying to understand how software gets constructed in their organization.  So this week and over the next four weeks, I am going to offer some helpful direction to people who find themselves as product owners.  We are getting DEEP in the month of April.

I am a big fan of Roman Pichler’s book “Agile Product Management with Scrum”.  This series of blog posts is going to draw heavily from his work on how to be a good product owner.  In the agile world there is a social compact.  The product owner sets priorities for what work gets completed.  The development team says how long it will take to do these priorities.  When the work is done they have a retrospective to assess what can be done better and faster.  Then the entire process starts all over again.  In order for this to be successful, the product owner has to create a backlog of work which follows the DEEP model.  A product backlog has to be detailed appropriately, estimated, emergent, and prioritized.  This week we will talk about how a product backlog should be detailed appropriately.

A backlog is nothing more than a series of user stories.  At a start-up or small business a user story can easily fit on a post it note or index card.  At a fortune 500 company requirements are often giant binders with mind numbing detail.  I feel there is a balance between the two extremes.  A user story should be in the following format and it is familiar to most people in the world of scrum:  As an "X " I want "Y " because of "Z".  This is the one sentence mission statement for the story.

Next, a user story should include the definition of done.  I have discovered that the best way to get developers and business people to effectively communicate what needs to be done is to use something from the world of test driven development: given, when, then statements.  The GWT syntax or Gherkin language is a perfect means to communicate what it means for the user story to be complete.  It also makes it possible for a developer to easily write unit and functional tests speeding up development in the long run.  When the development team reviews a story, I usually demand that stories include GWT statements for both affirmative and negative situations.  This way we avoid a lot of recriminations during the retrospective when a product owner says we did not finish our work.  A given, when then tends to clarify what it means to be done.

So each user story in your backlog should include a mission statement of what needs to get done, and enough GWT statements to cover positive and negative outcomes.  UML diagrams, attachments of XML, and wire-frames are helpful but not necessary for a story to be detailed appropriately.  As a scrum master it is up to you to train the Product Owners to have user stories which are detailed appropriately.  Next week, we are going to cover what it means to have stories estimated in a product backlog.

Until next time.