Tag: backlog refinement

A Product Owner’s Answer to Who Writes User Stories in SAFe

Posted on

Who writes user stories? 

Based on the Product Owner (PO) Framework article, POs manage and prioritize the team backlog. 

However, this doesn’t directly answer who writes user stories. Does managing and prioritizing include writing stories? Should POs write most or all of the stories? Or should the Agile Teams? 

This question arose when a new PO asked me for ideas for her team. She asked me, “Who writes the stories on your team?”  

Although I gave the new PO an answer about my team, how we worked, and shared who touches stories, this basic question stayed with me. 

Who should write the user stories? 

Here are three potential answers to consider:

  • Agile teams should write the user stories
  • POs should write the user stories
  • It depends on the situation

I’ll explain my reasoning and how I reached for SAFe® guidance considering each possible answer. I also hope you’ll check out the user story-writing resources at the end of this post.

How to determine who should write user stories

When Agile teams should write the user stories

Lean-Agile leaders have acknowledged a game-changing truth: attempting to ‘manage’ knowledge workers with traditional task management is counterproductive. Management visionary Peter Drucker was one of the first to point this out: “That [knowledge workers] know more about their job than anybody else in the organization is part of the definition of knowledge workers.

—SAFe Principle #8 article

To help answer the question of who writes user stories, I turned first to SAFe Principle #8, Unlock the intrinsic motivation of knowledge workers.

The importance of unlocking the intrinsic motivation of knowledge workers was never more apparent to me than when I became a PO. Many of my teammates had more experience with their expertise area and working on our courses than I did. 

This applies across many fields, products, and enterprises: your teammates become experts in what they are doing because most of us want to succeed at work. Thinking about how to help your team individually and collectively find motivation is key, and recognizing team members’ expertise is a crucial way to build trust and respect to lead the work effectively. 

The language in Principle #8 reminds me to define my role and sphere of influence. As a PO, I don’t manage people. However, for my team to produce great learning content, I must care about their knowledge, ideas, experiences, and expertise at each juncture of planning, refining, and iterating on the work they’re doing. 

On my team, Agile teammates usually write user stories. Every teammate has expertise that I don’t have. It would be foolish of me as a PO to write every story when someone else on my team understands the details about accomplishing the work more than I do. 

If I tried to represent their work by defining and writing every story, it could lead to too much rewriting. Rewriting a story is fine as we refine and understand more details and can often be done as a team activity alongside Backlog Refinement, estimation, and even Iteration Planning and it can be streamlined when the right expertise is applied as the story is discussed. 

If I wrote every story, I’d probably have to consult on and rewrite plenty (most) of them. Worse, it could demotivate my teammates if every story was dictated by their PO. 

That said, what I do as my team refines stories is:

1. Provide a strong voice in crafting acceptance criteria

2. Remind the team of our definition of done for work

3. Share who the customer is, and what they want

4. Work with the team (collectively and individually) on what counts as a “minimum viable story” for our backlog. 

You’ll find an example of a minimum viable story at the end of this post.

Why POs should manage, but not always write, user stories

While any team member can write stories at any time, it is the PO’s responsibility to ensure that they are well-formed and aligned with product strategy. The PO clarifies story details, applies user-story voice, ensures ‘INVEST’ characteristics are present, assists with story splitting, defines enablers, and incorporates behavior-driven design (BDD) to ensure stories support continuous value flow. The PO also allows space for ‘local’ stories and spikes that advance product design but are not derived explicitly from ART-level features.

—Product Owner article

My second answer to who writes user stories comes from the PO Framework article. 

POs “manage”  the team’s backlog and have content authority. This can mistakenly turn into an expectation that POs write the stories.

POs may write all the stories if:

1. Agile teams are not yet feeling the benefits of transformation. Therefore, they may be slow to embrace the work of writing stories themselves. It can become “another thing to do” or “taking time away from doing the actual work.” 

2. They want to ensure the ART and team backlogs are aligned, and stories in the team’s backlog meet the definition of done and support ART progress.

However, if the PO writes every story, they will have little time to perform all the functions POs are otherwise busy with!

For me, it’s important to note the Framework talks about management, not authorship. In fact, the PO article talks about guiding story creation rather than authoring stories.

We don’t find SAFe specifying that POs author the team backlog. What a PO does in order to manage the backlog and guide story creation is both different and deeper than simply writing everything in it:

  • Strategizing across the ART to meet ART-level objectives
  • Working with Product Managers, Business Owners, and the RTE to deeply understand the matrix of metrics the ART is using, strategic themes, and how both are applied 
  • Working closely with Product Managers, who own the ART Backlog, to refine features
  • Working closely with the team and stakeholders to decompose features into stories
  • Ensuring stories meet user needs and satisfy the team’s definition of done
  • Being the go-to person to share decisions the team is making on “how” to complete the work and how it may show up in meeting objectives
  • Prioritizing which work to do when so the team can accomplish its goals and contribute to the ART goals while maintaining flow

Here is the guidance I shared with another PO on the idea of the PO writing every story.

Becoming a story-writing PO will:

  • Create demonstrable work for the PO
  • Codify the (damaging) idea that writing stories is a bureaucratic task
  • Lead to future disagreements or dissatisfaction about what should be included in the scope of this work
  • Set POs up to be the target for those disagreements and dissatisfactions

Here’s what it won’t do. 

It won’t remove the need for teams to plan their work together to achieve flow or avoid rework or misunderstandings about what value is being delivered or how the team is delivering it.

For these reasons, I refuse to become a story-writing PO. I insist my team come together to discuss work and decide who is best informed to write a story. I further drive us to consider all of our stories in refinement so there are multiple teammate eyes on it. 

The immediate result of this process with some of my teammates early on was frustration: “I’m so busy that asking me to write about my work instead of doing it feels like you’re wasting my time.” 

Over time, it has borne other, much more nourishing fruit for the team, including: 

  • More paired work and team stories
  • Better flow and processes to manage flow
  • Growth of T-shaped skills
  • Improved understanding and thought about customer centricity across the team
  • An understanding of each other’s areas of expertise and how work connects on a cross-functional team

If you have teammates who resist writing stories, I recommend you surface this conflict sooner than later and work through it upfront.

The most knowledgeable people write the user stories

I believe the best answer to who writes user stories is the answer to “Who knows the most about this work?” 

Sometimes the answer may be the PO because they’ve gathered the most information. 

In this case, it’s best for the PO to write the story. 

  1. I have been in an org-wide or ART-level meeting and know about work for every team. This has included tooling updates, requests to prepare specific demos of our work for different kinds of audiences, work around specific milestones, or professional development requests. 
  2. It is work that came out of my meetings with other teams to service dependencies. 
  3. It is walk-up work coming from changes or needs that weren’t surfaced before. 
  4. Talking with an internal or external customer helped me understand a need we had not previously written stories to meet.

It is rare I would write a story for work I am doing. In the above cases, the work would be handled by the team. By writing the story, I am capturing the need as I understand it but not carving the story in stone. 

When thinking of how stories enter the backlog, I find it useful to remember the three Cs of story writing: 

  • Card
  • Conversation
  • Confirmation

The C for conversation is most relevant to my mindset on this. The story is a promise our team will discuss this need and decide how to deliver value on it. 

The conversation could include: 

  • Refining our understanding of the user and their need
  • Revising acceptance criteria
  • Discussing who might start the work on it or how the team will deliver the work’s value 

This is the minimum viable story criteria my team uses.

Example of a minimum viable user story

1. Story title: Provide a name that accurately describes the work
2. What: Give a description of the work
3. Activities or tasks: Break down what it will take to complete this work
4. Acceptance criteria: This answers the question, “What can we or our customers do now that we or they could not before?” or “How will we know this is done?”
5. Parent: Connect it to a feature where possible
6. Tags: We note if this is a team story (more than one person tagged) or an individual contributor’s work (a single person tagged)
7. PI and Iteration: When we expect to start and complete this work

I encourage you to use this template as a jumping-off point. 

Look through your backlog and think about who is and could write user stories with the most thoughtful details.

Story-writing resources

Now that I’ve shared my answer to who writes user stories, here are some resources to help write them.

If you want to receive helpful content like this for your role, don’t forget to set your role in SAFe Studio. This allows us to bring the best content to your SAFe Studio homepage. Set your role in SAFe Studio today.

Set your role in SAFe Studio Log in now

About Christie Veitch

As a writer and education nerd who loves processes, Christie seeks to move the needle on what learners can do and what educators and trainers will try with learners. She designs and delivers compelling content and training and builds communities of avid fans using these resources as a Scaled Agile, Inc. Product Owner. Connect with Christie on LinkedIn.

Large Solution Refinement: Paving the Super-Highway of Value Delivery

Posted on

This post is the second in a series about success patterns for large solutions. Read the first post here.

Backlog refinement is integral to the Scrum process because it prevents surprises and maintains flow in iterative development. Regular backlog review ensures the backlog is ready for iteration planning. An Agile team understands how much they still need to refine the backlog items before the next iteration planning and beyond.

When applying SAFe® to large, complex, cyber-physical systems, you must expand backlog refinement to include more viewpoints. The complexity of a large solution is rarely fully comprehended by one or a few individuals, and the size of the large solution exacerbates the impact of risks that can escape into large solution planning.

So how do we find the balance between overpreparation, which limits ownership and innovation by the solution builders, and under-refinement, which can undermine the solution and the flow of value delivery?

To answer these questions, we adapted the following success patterns for large solution backlog refinement.

Use the Dispatcher Clause

The dispatcher principle guides large solution refinement by preventing the premature dispatch of requirements to Agile Release Trains (ARTs), solution areas, or Agile teams. Premature dispatching can cause risks like:

• Misalignment in the development of different solution components
• Missed opportunities for economies of scale across organizational constructs
• Sub-optimization of lower priority solution features

In contrast, making the right trade-off decisions at the right level drives holistic and innovative solutions.

Key stakeholder viewpoints that are often overlooked include marketing, compliance, customer support, and finance. Ensuring these voices are heard during refinement work can prevent issues that might remain undetected until late in the solution roadmap.

For complex solutions, we discovered that a planning conference is more effective than pre-and post-PI Planning events alone. This event mimics a PI Planning event and is intended to align upcoming PI work across ARTs and solution areas. To keep the conference focused and productive, it should only include representatives from the participating ARTs. We will cover specific planning conference details in a later blog post.

The goal of the planning conference is to provide a boundary for the large solution refinement work. Preparation for key decisions that can be made in the planning conference should be part of the refinement work. But making key decisions is part of the planning conference. However, key stakeholder inputs that cannot be reasonably gathered during the planning conference should be included in the refinement work.

For example, in Figure one, a review of the key behavior-driven development (BDD) demo and testing scenarios by a customer advisory board is valuable input in refinement. The customer advisory board will not attend the two-day planning conference, so their advance input provides guardrails on the backlog work that’s considered.

Agree on the Definition of Ready

The definition of the readiness (DoR) criteria for a large solution backlog is often multidimensional. Consider, for example, the architectural dimension of the solution. The architecture defines the high-level solution components and how they interact to provide value. The choice of components is relevant to system architects in the contributing ARTs and stakeholders in at least these areas:

• User experience
• Compliance
• Internal audit and standards
• Corporate reuse
• Finance  

Advancing the backlog item—a Capability or an Epic—through the stages of readiness often requires review and refinement from the various stakeholders.

Figure one is an example Definition of Ready Maturity Model. It shows the solution dimensions that must be refined in preparation for the solution backlog. Levels zero to five show how readiness can advance within each dimension. The horizontal contour lines show that progression to the intermediate stages of readiness is often a combination of different levels in each dimension.

Applying SAFe for Agility
Figure 1. Definition of Ready Maturity Model example

This delineation is helpful when monitoring the progression of a backlog item to intermediate readiness stages on a Kanban board.

The key to balancing over-preparation and under-refinement is to distinguish between work that an ART or solution area can complete independently without a high risk of rework. For example, final costs could be prohibitively high without a Lean business case to scope the solution. Another common high-risk impact of under-refinement is unacceptable usability caused by the siloed implementation of Features by the ARTs.

The Priority BDD and Test Scenarios in Figure one represent how features are used harmoniously. These scenarios provide guardrails to help ARTs prioritize and demonstrate parts of the overall solution without significant rework of a PI.

Identifying the dimensions, levels, and progression of readiness is a powerful organizational skill for building a large solution.

Leverage Refinement Crews

Regular large solution refinement is necessary to ensure readiness. The complexity of a large solution warrants greater effort and participation than Solution Management can cover. And the number of key decisions grows in direct proportion to the size of a solution.

Our experience shows that roughly 10 percent of those who participate in large solution development should participate in a regular refinement cadence. If the total participation is 450 people, then 45 representatives from across ARTs or solution areas should set aside time for weekly refinement iterations.

Backlog refinement for a large solution requires more capacity than a typical backlog refinement session. The refinement crews determine a cadence of planning, executing, and demonstrating the refinement work. One-week iterations, for example, help drive focus on refinement to ensure readiness.

We also discovered that refinement crews of six to eight people should swarm refinement work within iterations. These groups are usually created based on individual skills and their representation within stakeholder groups. Alignment with crews and dimensions or skillsets is determined during the planning of refinement iterations. The goal is always to move the funnel item to the next refinement maturity level in the next iteration.

Our experience says that each refinement crew requires at least three to four core participants. The other crew members can come from stakeholder organizations outside the Solution Train.

Readiness progress must be reviewed on a regular cadence with solution train progress. Progress can be represented in the Solution Kanban between the Funnel and Backlog stages, as shown in Figure two. In our example, these stages replace the Analyzing state provided as a starting point in SAFe.

Applying SAFe for Agility
Figure 2. Refinement Stages in Solution Kanban

The organization must also allow each refinement step to vary over time, as it makes sense for the solution. For example, as the development of the solution progresses toward a releasable version, the architecture should stabilize. Therefore the readiness of the backlog item in the architecture dimension should progress very quickly, if not skip some readiness steps. As solutions approach a major release, the contributors’ capacity can shift from readiness to execution of the current release or readiness for the next release.

Because refinement happens in a regular cadence of iterations, weekly, for example, the refinement crews should be empowered to make these decisions in refinement iteration planning.

Employ Dynamic Agility

So is there a definitive template of dimensions with levels and a step-by-step process for determining the DoR? Not quite. And we don’t think that a prescriptive process is best for most organizations.

Instead, we advocate for using the organizational skill of dynamic agility.

As the size and complexity of a solution grow, so do the number and type of variables: compliance type, hardware types, skills required, size of the development organization, size of the enterprise/business, specialization of customer types, and so on. This complexity is augmented by company culture challenges, workforce turnover, and technology advancements in emerging industries.

Individuals’ motivation and innovation suffer when they get lost in the morass of complexity. When things don’t get done, more employees are added to help fix the problem. This workforce growth only magnifies the complexity again.

In contrast, the organizational skill of dynamic agility stimulates autonomy, mastery, and purpose for individuals within teams, teams-of-teams, and large solutions.

Consider the House of Dynamic Agility represented in Figure three.

Applying SAFe for Agility
Figure 3. House of Dynamic Agility

How can dynamic agility be applied to large solution refinement? DoR identification and maintenance of its dimensions and levels happen through a regular cadence of the right events. How often should these occur, for how long, and who should attend? What elements will represent and communicate the DoR? What roles are best suited to own and facilitate the management and use of DoR over time? How will collaboration across the organization happen most efficiently for maximum benefit? These questions are best determined in the context of the large solution.

Conclusion

Large solutions require a balance of preparation and execution to achieve an optimal flow of value. Conducting backlog refinement in preparation for a large solution planning conference and PI Planning lets decomposed work items be implemented without risk of rework. Avoiding over-specification in refinement allows ARTs to innovate and accomplish within the guardrails of refinement. Enabling large solutions to leverage dynamic agility builds ownership, collaboration, and efficiency in a large-scale endeavor.

Look for the next post in our series, coming soon.

About Cindy VanEpps, Project & Team, Inc.

Cindy VanEpps - SAFe® Program Consultant Trainer (SPCT)

From crafting space shuttle flight design and mission control software at Johnson Space Center to roles including software developer, technical lead, development manager, consultant, and solution developer, Cindy has an extensive repertoire of skills and experience. As a SAFe® Program Consultant Trainer (SPCT) and Model-based Systems Engineering (MBSE) expert, her thought leadership, teaching, and consulting rely on pragmatism in the application of Agile practices.

About Wolfgang Brandhuber, Project & Team, Inc.

Chief Scrum Master, and Agile Head Coach in various Agile environments

Dr. Wolfgang Brandhuber has been a Scrum Developer, Product Owner, Scrum Master, Chief Scrum Master, and Agile Head Coach in various Agile environments. His passion is large solutions. Since the advent of the large solution level in the Scaled Agile Framework in 2016, he has set up and helped solution trains improve their complex systems. During his 18 years as a professional consultant, he worked over 16 of those in the Agile world and more than nine years with SAFe. Among other certifications, he is a certified SAFe® Program Consultant Trainer (SPCT), a Kanban University Trainer (AKT), and an Agility Health Trainer (AHT).

About Malte Kumlehn, Project & Team, Inc.

Malte Kumlehn, Project & Team, Inc.

Malte helps deliver complex ecosystems, people, Cloud, AI, and data-powered digital transformations toward business agility. He pioneers intelligent operating models for portfolios with large solutions as a SAFe® Fellow, advisory board member, and executive advisor in this field. He guides executives in developing the most challenging competencies that allow them to deliver breakthrough results through Lean-Agile at scale. His experience has been published by Accenture, Gartner, and the Swiss Association for Quality over the last ten years.

Learn more about Project & Team.