You’ve met them: slightly curved back, eyes glued to the screen, minimized font size and a 14 step template in Jira. Story, check. Acceptance criteria check. Examples, check. Logfiles, hmm still have to run that query. Mockups, check. Test scenarios, check. Linking all previously known issues to this one, in progress, compare it to the definition of ready, next week. Discussions with the Developers and Stakeholders lead to an updated template or a simple statement: “The details are in the ticket.”
The Story Writer, or scribe writes ideas and information on behalf of another, sometimes copying from another document, sometimes from oral instruction on behalf of an illiterate person, sometimes transcribing from another medium such as a tape recording, shorthand, or personal notes.
— Wikipedia, Oktober 2019 —
The Story Writer is also referred to as the scribe, secretary, business analyst, technical writer, and note taker.
The Product Owner as a Story Writer
It’s often in the language that you can detect a Story Writer. Many conversations are about the details in the Product Backlog Item. Teams push back when work is not compliant with the definition of ready, which feels more like a contract than a handy checklist. When the increment does not produce the effect we are trying to achieve it is seen as a problem in the description; spikes, designs, and “research stories” are commonplace.
With the many Product Owners and Product Managers we have trained and coached in their daily practice, we’ve observed the following patterns in Product Owners that we would classify as Story Writers:
- The Story Writer typically has a very well-organized Product Backlog. The Product Backlog Items (typically user stories) on the top are really small, really clear, specified, designed, detailed, estimated, and refined to be 100% perfectly clear. Story Writers are focussed on specifying the work to a great level of detail, making sure that the Development Team has no further questions because all the details are in the tickets.
- The Story Writer has a keen eye for details and they love to “dig in” into all the nitty-gritty stuff. Story Writers are great at specifying user stories. They tend to write user stories, acceptance criteria, and functional descriptions all day long.
- Other associated behaviors with the Story Writer type of Product Owner are: acting as a business analyst, acting as a technical writer, legacy system copy cat, scribe and note taker.
There are many reasons that cause this behavior, but the one we see the most is “Scrum-In-Name-Only” or SINO culture. Where people go through the motions of Scrum without living through the mindset behind it. Fellow Scrum Trainers Barry and Christiaan have even developed a detector for it.
The root cause lies in a Tayloristic mindset where it seems more efficient to separate the thinking from the doing. Therefore the team likes the detailed stories, so they can’t be blamed for building the wrong thing, and the Product Owner maximizes the output of the team since they don’t spend time thinking about alternative solutions. So, no waste!
In a complex domain, the true waste is not using the brains of the people you work with. Have a discussion, and if you need to, get it written down.
The results/effects of acting like a Story Writer
Obviously, not all (Product Owner) Story Writers are the same, and not all the results/effects may be visible in your context. That being said though, what we typically observe when Product Owners act like Story Writers is:
- Too much focus on the details, typically not limited to ‘what’ and ‘why’, but also including acceptance criteria, maybe designs/sketches, functional and or technical documentation, etc. This is too much detail for a Product Owner to write down;
- Typically Story Writers have no vision and strategy in place, and/or aren’t actively sharing the vision and strategy with the Scrum Team and its stakeholders;
- Focus on details, effects, and short term results;
- No focus on long term outcomes (TCO, ROI, P&L, etc);
- The Scrum Team slows down;
- The Scrum Team remains to be dependent on the Product Owner, which will eventually slow the team down;
- The Scrum Team isn’t learning and obtaining more business, domain, customer, and product knowledge. This prevents them from making better, faster, and more informed decisions and herewith increase self-organization;
- Being the carrier pigeon leads between the Scrum Team and the stakeholders transforms the original feedback and message from the stakeholders, which gets delivered to the Scrum Team differently. The most valuable feedback for Developers is the feedback they receive from the stakeholders directly. Don’t be a filter between them;
- The Scrum Team isn’t learning to be self-organizing their own work, they won’t be taking ownership (over planning, results, quality, etc), and controlling everything will cost you a lot more work and time yourself (which you can’t spend on more important things);
What you can do to move away from this stance
There’s nothing wrong with having a well ordered and structured Product Backlog. There are nothing wrong with well-described, clearly articulated Product Backlog Items. In fact, you take a look at the Scrum guide under the chapter of the Product Backlog. It doesn’t tell you how to do it, or that you have to do it by yourself.
Want to learn more?
This is a blog from the Stances of the Product Owner series, in which Professional Scrum Product Owner Trainers and Consultants Chris Lukassenand Robbin Schuurman explore preferred and misunderstood stances (attitudes) of Product Owners and (Agile) Product Managers. Read more about the Stances of the Product Owner on this page.
Go experience the Stances of the Product Owner!
If you’re a Product Owner, Product Manager, Scrum Master or Agile Coach with about a year (or more) of experience under your belt, go and explore the Stances of the Product Owner in the Professional Scrum Product Owner Advanced class. Find a trainer to your liking or in your area, and deepen and expand your Product Management knowledge and skills. And let us know what you think about the training! What did you like? What can be improved? Let’s collaborate to take the profession of Product Ownership to the next level.
If you’d like to experience the all-new Professional Scrum Product Owner Advanced class, go to Scrum.org to find a class in your area. If you’d like to participate in one of our classes, check out our Xebia Academy page for more information or inquire for an in-house class via training@xebia.com.