Chris Lukassen — November 24, 2019 
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 Development Team 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 the Development Team is the feedback they receive from the stakeholders directly. Don’t be a filter between them;
- The Development 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 is 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.
Business & Finance Articles on Business 2 Community
(58)
