SAFe Backlogs 1.3

Now that you have all of those backlogs organized, you should build something with them! Now that you have all of those backlogs organized, you should build something with them!
PrevNext
Page 1 of 4

Introduction 

Thanks for sticking with us through this three part series on SAFe backlogs! We've finally arrived at the final portion, where we'll be talking about the actual work items themselves. To date we've gotten a good look at the "lay of the land" and seen where all of the SAFe backlogs exist, as well as taken a deeper look at how they feed each other and help shape an organization's approach to work. Along the way we've talked about the work items in broad terms, but now we are going to dive into all of them.

The Iron Triangle 

Everyone knows the Iron Triangle. It's that beautiful, and at the same time awful, method of looking at projects that highlights the three constraints: resources, schedule, and features. I don't want to review the triangle, or even use it as it is intended here. However, it does make a great lens through which we can view the various SAFe backlog items.

When talking about the work items I like to use the three sides of the triangle to set the scope of that work item. As you move up or down the hierarchy of items you'll find that all three constraints (functionality, resources and time) will scale appropriately. This view should help you keep track of which work item covers what scope across those three factors.

Let's start at the bottom and build our way up.

Stories 

Scope:
  1. Functionality: A small, vertical slice of user functionality
  2. Resources: One single team
  3. Time: One single iteration
Location:
  • Team Backlogs

Defining Aspect:
  • Must include everything needed to be functional (design, dev, test, deploy, etc)

Description:

Stories are the lingua franca of development teams and describe the actual work needed to implement the intended system. Every other work item on this list describes the system intent, but stories describe the actual work to be done to realize that intent. The story should have a description that talks about

  1. an intended customer interaction
  2. a beneficial outcome
  3. a system behavior or function

In all three cases the story description talks about the destination, it does not describe the path to get there; and all three are concerned with the nuts and bolts implementation of the strategic theme or the value stream that governs this train. In other words, your stories should tell your team what to build but not how to build it.

A common hazard with stories, especially in organizations new to any type of agile is that they become containers for requirements. I see this in companies who are having a hard time trusting the story to get the job done. Instead of a long list of requirements, the story's acceptance criteria and definition of done should be used to help decide what is and is not acceptable work.

With that in mind, a good story will have three pieces of content:

  1. Story description
  2. Acceptance criteria
  3. Definition of done

None of these should be long, extended laundry lists; instead they should all be brief and to the point. This brevity is critical to striking the perfect balance between management being proscriptive and the development team over-developing the work. Being out of balance in either direction can be disaster. The local context will have a huge impact on what that perfect balance looks like, and can be a maturing factor in how the team's stories are crafted.

At the end of each iteration, every team must demonstrate its stories in concert with every other team on that train. All work should be shown in a fully integrated environment, fully functional and playing nice with all other code written by other teams on the same train. This integration is critical because it is the primary method that SAFe uses to mitigate the risk of cross-team dependencies. Catching collisions between team's work is usually quite a bit less painful at the iteration boundary than catching them as part of a larger deployment push; say, every quarter or so. Less code to integrate means fewer issues, and at every level of SAFe, this framework pushes for smaller, tighter work items.


Resources:

All stories should be scoped so that a single development team can get them to done, with all testing and integration! While the team's Product Owner is the single person responsible for this scoping, the entire team must be involved in the crafting of these stories. Remember that the story itself is not valuable to the organization; the shared vision of what is needed is where the real value lies. That shared vision cannot be built when the PO writes her stories in a vacuum, and then only shares that vision at the team's Iteration Planning event. The entire team should be talking, crafting and writing stories throughout every iteration.


TimeBox:

Each story should fit within a single iteration of the team's effort. For most SAFe implementation, this is a two-week timebox. Since the story is scoped on a team-by-team basis, not every team's stories will be of the same size. But keep in mind that each story should be able to get completely to done within this two-week timebox. Yes, architecting your teams so that they can achieve this can be a pain, but this single statement is about as fundamental of a step towards true agility as you will ever take. If your teams are truly cross-functional, then you have built the foundation that all of the rest of your agile wins will be built upon.


Enabler Stories:

Enabler stories have all of the same aspects as a user story with two exceptions.

  1. They are not written in a user voice, because…
  2. They do not focus on the user.

The user voice is the standard form of writing a story description that goes, "As an X, I want Y, so that Z." Since the target audience of all enablers is the development team themselves, it is acceptable to write their description in language the team can understand. Enabler stories talk about things that need to be done in order to 'enable' the delivery of the actual user stories. As such they are the fundamental input to the architectural runway and their development work will need to precede the consuming story's work by at least a sprint or more. So where a user story will deliver a piece of functionality to the user, an enabler story will deliver a piece of exploration, architecture, infrastructure or compliance back to the development team. Outside of that change, they will still have descriptions, acceptance criteria and definition of done. They will still be sized and demo'ed and they will still fit within one iteration and are deliverable by one team.



PrevNext
Systems Thinking for the Field Agilist - Download
SAFe Backlogs 1.2

Related Posts

 

Comments

No comments made yet. Be the first to submit a comment
Already Registered? Login Here
Guest
Friday, 23 August 2019
If you'd like to register, please fill in the username, password and name fields.