A good product owner or business analyst is crucial to much of a product’s success. If you have the luxury of being allowed to attend proper training prior to starting your role, that’s great. In practice, we often see that people (have to) start untrained in such a role and have to develop a way of working by themselves. I myself worked for years in this type of role, and often had to find out on Google what were useful practices. Recognizable? Then read on …
How do I create clarity for my development team?
If you’re a product owner or business analyst on a development team, you’ve probably asked yourself the question, “How do I make sure the desired functionality is clear to my team? How do I make sure I write stories that give clear input to the developers and testers? And how do I slice the work into useful stories? In this blog, you’ll find three tips for writing good stories in advance.
Tip 1. Create a hierarchy of Epics, Features and Stories
Stories contain a detailed description of what is to be built. In addition, it is also advisable to look at your assignment with a somewhat broader view. To do this, use Features or Epics.
An Epic describes big new ideas that require an investment to be developed. An Epic usually takes longer than a quarter to build. With an Epic, you also think about the business case: “Is this solution worth this investment?
Features you build within a quarter and include a concrete piece of functionality. In doing so, you can layer in some level of detail and look at the Benefit you will deliver for your client. You then split the feature into a number of Stories.
By establishing a hierarchy in your Epics, Features and Stories, you get a feel for how big of an item you are developing and what level of detail is desired. This allows you to test at the story level against your Epical Feature whether this story is actually needed to achieve your goal so that you don’t overdevelop. Establishing hierarchy helps you structure main and side issues: the right information at the right time.
Tip 2. Use Acceptance Criteria as part of your Story
Acceptance criteria clearly define for the team the answer to the question, “What will I have if I have built this story? Acceptance criteria are therefore good input for the developer, as well as for the tester. By writing acceptance criteria uniformly and clearly, you help your team quickly understand what the desired functionality is. Suppose; the user story syntax is:
As an employee, I want to be able to make a lot of coffee so that I can provide coffee for all my colleagues.
Here the acceptance criteria could be:
1. Coffee maker can brew <many coffees>
<lots of coffee> = at least 12 cups
2. Coffee maker can brew coffee <fast>
<fast coffee brewing> = 1 cup of coffee is brewed in 5 seconds.
Tip 3. Why, why, why, why, why, why …?
Of course, writing a good story is not only about clearly writing out exactly what the product is supposed to do, but also that the product delivers the right value for your customer. One way to do this is to ask yourself five consecutive times about the “why” of a particular decision or action. Why are we developing this? Why is this important to our client? Keep asking this question consistently ensures that you develop only what the customer is really going to use. So always keep asking yourself and others the “why” question.
Learn more about the training course ‘Writing Epics Features & Stories’?
We provide practically applicable training on this subject that we are happy to tailor to your work situation. For this reason, our trainings are always in-company. This way you will learn to apply the same principles with your colleagues, using the same tools in the same language. This also makes it easier to spar together afterwards about your Stories.
