The author of the story (a misunderstood position of product owner)

You’ve met them: Slightly curved back, eyes glued to the screen, reduced font size, and 14-step model in Jira. History, check. Verification of acceptance criteria. Examples, check. Log files, hmm have yet to perform this query. Mockups, check. Test scenarios, control. Linking all the previously known issues to this one, in progress, compare it to the loan definition, 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 writer of history, Where scribe writes ideas and information on behalf of another, sometimes by copying from another document, sometimes from oral instructions on behalf of an illiterate person, sometimes by transcribing from another medium such than a recording, shorthand or personal notes.
– Wikipedia, October 2019 –

The author of the story is also called the scribe, Secretary, business analyst, technical writer and note taker.

The Product Owner as Story Writer

It is often in the language that we can detect a Story Writer. A lot of the conversations are about the details of the product backlog item. Teams push back when work doesn’t meet the definition of a loan, which is more like a contract than a practical checklist. When the increment does not produce the effect we are trying to achieve, that is considered a problem in the description; tips, designs and “research stories” are commonplace.

With the many Product Owners and Product Managers that we have trained and coached in their daily practice, we have observed the following models among Product Owners that we would qualify as Story Writers:

• The Writer generally has a very well organized Product Backlog. The Product Backlog items (usually user stories) at the top are really small, really clear, specified, designed, detailed, estimated, and fine-tuned to be 100% perfectly clear. Story writers focus on specifying the job with a high level of detail, making sure the development team has no further questions as all the details are in the tickets.
• The Writer has a keen eye for detail and love to “dig” into every detail. Story writers are great at specifying user stories. They tend to write user stories, acceptance criteria, and functional descriptions throughout the day.
• Other behaviors associated with Writer The types of Product Owner are: acting as a business analyst, acting as a technical writer, legacy system copier, scribe, and note taker.

There are many reasons that cause this behavior, but the one we see the most is the “Scrum-In-Name-Only” or SINO culture. Where people follow the movements of Scrum without experiencing the mindset behind it. The fellow Scrum trainers Barry and Christiaan even developed a detector for that.

The root cause lies in a Taylorist mindset where it seems more effective to separate thought from action. Therefore, the team loves detailed stories, so they can’t be blamed for building the wrong thing, and the Product Owner maximizes the team’s performance because they don’t spend time thinking about alternative solutions. So, no waste!

In a complex area, the real waste is not using the brains of the people you work with. Have a discussion, and if you need to, write it down.

The results / effects of acting as a screenwriter

Obviously, not all (Product Owner) Story writers are the same, and not all results / effects may be visible in your context. That being said, what we typically observe when Product Owners act like Story writers is:

• Too much focus on details, usually not limited to ‘what’ and ‘why’ but also acceptance criteria, maybe designs / drawings, functional and / or technical documentation etc. It’s too much detail for a product owner to write down;
• Typically, story writers do not have a vision and strategy in place, and / or do not actively share the vision and strategy with the Scrum team and its stakeholders;
• Focus on details, effects and short-term results;
• No focus on long-term results (TCO, ROI, P&L, etc.);
• The Scrum team slows down;
• The Scrum team remains dependent on the Product Owner, which will eventually slow down the team;
• The Scrum team does not learn or acquire more business, domain, customer and product knowledge. This prevents them from making better, faster and more informed decisions and thus increases self-organization;
• Being the carrier pigeon between the Scrum team and stakeholders transforms the original stakeholder feedback and message, which is conveyed differently to the Scrum team. The most valuable feedback for the development team is the feedback they receive directly from stakeholders. Don’t be a filter between them;
• The development team does not learn to self-organize its own work, it will not take ownership (on planning, results, quality, etc.) and controlling everything will cost you a lot more work and money. time yourself (what you can not spend on more important things);

What you can do to get away from this position

There is nothing wrong with having a well-ordered and structured Product Backlog. There is nothing wrong with well described and clearly articulated product backlog elements. In fact, you take a look at the Scrum guide under the Product Backlog chapter. It doesn’t tell you how to do it, or that you have to do it yourself.

---