Big user stories

Sometimes as a product owner you run into the problem of having to deliver a large piece of a project.  As mentioned on a previous post you want to avoid going to technical and constraining a dev team to follow what you’ve written when instead a story is the beginning of a conversation and isn’t a commitment to exactly how something should be done.  With a user story though you don’t want it to be too big and so you need to break it down into manageable parts. 

If for example you need your team to create a new micro-service to process requests for information you don’t want to write a story that doesn’t create any value once completed.  An example of this would be writing a story that addresses the need to create a database for a user to send, receive, and update information from.  Instead you’d write a story that starts perhaps with the first part of the process, i.e. send data.  With this broken out into its own story it should be discussed with the dev team that while we know that doesn’t encompass creating a database, receiving info, or updating info they will inherently know or be explicitly told that a database needs to be created in order to complete this story.  It should be noted that the very first story will also be front loaded with initial set up and configuration of other things and so it may be larger than subsequent stories.  That is ok though because we want a story to be able to stand on its own in terms of value being delivered even if it is only one portion of data being worked on, in this case sending information. 

What to do and not do when writing a user story

When writing your story don’t include the “How” it should be done.  That is up to the dev team to figure out the best way to do that and then create tasks/sub tasks to complete those things.  Dipping your toe in the “How” waters can lead to constraining a story to follow what you have written.  You also run the risk of getting too involved with the details of how the story and value is to be delivered and that can lead you to spending time on things that don’t need your attention, which then detracts from continuing to gather requirements and prioritize which valuable things need to be done first.

When writing acceptance criteria, it is important to write them so that you tell the developer and QA resources what you want them to test against.  All acceptance criteria should be testable.  A bad example would be, “X technology passes a flag to X other technology so that a customer doesn’t have tax withheld from their order”.  Instead a better example would be, “Demonstrate that a customer can click a button to then have taxes withheld from their order.”  The first example is too specific and limiting.  The second lets the dev team decide how to make something happen but is easy to demonstrate that it works or not, i.e. if it was done right this would be the result.

5 Whys

As I dive deeper into my role as a product owner, I am constantly looking for ways to improve to make things easier for my stake holders, coworkers, and dev team.  One of the things I’ve picked up when writing a user story is to utilize what is called the “5 Whys”. 

To help clarify a description of a story and the value to be delivered, which is then subsequently distilled down to acceptance criteria that a dev codes to and a QA resource tests against, asking “Why” leads the writer of the story to really drill down to what the value is that needs to be delivered.  It helps clarify unknown requirements at times and makes a story concise and easy to understand.