Team Backlog Evolution in SAFe - from 3 words on a sticky to a Ready to Play story

Introduction

The PI planning event provides a great pattern for filling a backlog, but its all too easy for teams to fail to capitalise on their great beginning with effective ongoing backlog refinement.

How do we get from those hastily scrawled post-it’s to fully articulated stories in user-voice form with comprehensive acceptance criteria? Given that many Release Trains move from “all-waterfall” to “all-agile” via a one-week quick-start, a solid set of starter pattern practices is a useful tool to help them accelerate their journey. This article focuses on the evolution of an individual backlog item. A follow-up article will cover techniques for managing the overall backlog.

Whose job is it?

In my early agile days, I learnt that a story was a token for an ongoing conversation between the team and their customer. The important thing was the conversation, some details of which needed to be preserved by writing them down.

Unfortunately, all too many people interpret user stories as “the new form of requirements”. They want to know who’s responsible. Does the Product Owner write the detailed stories and hand them to the team? Does the BA work with the Product Owner to do so? These are depressingly common anti-patterns, and our first mission is to avoid them. Story evolution is a collaborative activity regardless of the stage of maturity of the story, and I always start teams off with the mantra that nobody writes alone.

PI planning sets the scene perfectly. Each team starts with an empty backlog, and over the course of the breakouts works with their product owner, product manager and subject matter experts to explore their features – recording the results of the exploration as a set of backlog items.

So we’ve started well by having a conversation and recording a set of tokens for the details of the conversation on post-its – how do we keep that good pattern going after we leave PI planning?

Does it always have to be the whole team?

Having the whole team involved in an activity is an expensive (and not always productive) exercise. While the fully shared context is desirable, it’s not always necessary or valuable. Involving the whole team in workshops in their early life for the shared learning is great, but most evolve reasonably rapidly to some variation of Jeff Patton’s “3 Amigos” or triad approach. Jeff describes a triad as “Product Owner, BA and developer” (the 3 amigos). I don’t tend to be quite as prescriptive – what I’m looking for is diversity of input, so I tend to recommend “one of each discipline”. The most common format for this is “Product Owner, BA, Dev, Tester” or “Product Owner, UX, Dev, Tester”.

One caveat to this is to make sure triad memberships rotate to spread knowledge. The Product Owner will be a constant, and if the team has a BA they’ll also usually be relatively constant but what we don’t want is a pattern where it’s always the “dev lead and lead tester”. The more the understanding of the problem domain is spread around the team, the better the outcome!

Moving to User Voice Form

Teams rarely generate great user voice form stories during PI planning. There just isn’t time. If we’re lucky, they might have done so for their first sprint but most of the backlog will consist of items like “pay by the month”.

It’s highly tempting to detail someone to go off and “upgrade the stories”, but we miss something. The point of user-voice-form is to help us to look through the eyes of our users. The discussion as we identify roles and “so that” reasons enriches our understanding of what we’re trying to accomplish. The last thing we want is for the team to miss out on that conversation.

So, the team should set a goal of having a “rolling 3 sprints” of backlog that’s been refined to user voice form and moving as rapidly as possible to achieving this after PI planning. It’s a pretty rapid activity, so usually not all that hard to achieve with a set of well-facilitated one hour workshops. There’s a good reason for this. As we move to user voice form, we flush new insights – often in the form of missed stories or missed complexity. It’s good to learn about this early in the PI.

Establishing a Definition of Ready

Nothing destroys a sprint like a poorly defined set of stories entering the gate. All teams are taught to establish a definition of done, but I’m a huge personal fan of a “Definition of Ready”. This defines the set of conditions a story must meet in order to be accepted into Sprint Planning.

Exactly how much or how little is required to “be ready” is highly dependent on context. In highly regulated environments this often includes signoffs from legal and risk on acceptance tests. These are folks not renowned for moving fast - discovering you need an approval from legal in the middle of the sprint is a recipe for an unfinished story and missed sprint goals.

A good question to seed the definition is “what are you likely to discover in the middle of the story that might take more than a couple of days to get an answer to?”. This then forms the guidelines for key things to answer when preparing the story. The rule of thumb I’ve found quite useful is getting the acceptance tests to “80% lockdown”. There are always some questions that will be revealed once developers crack the story open, but the “80% rule” enables an approach where “if the expectation just changed by more than the 20% we allowed for the new detail its fuel for another story and a future sprint”.

My strong recommendation to all teams is “provide all the detail in your acceptance tests”. The temptation to elaborate the story by filling in tables of business rules and bullet point acceptance criteria before developing acceptance tests just leads to waste and redundancy. Using techniques like Specification by Example or BDD workshops take you straight to acceptance tests and provide very useful ways of exploring the problem domain collaboratively.

Employing a definition of ready as well as a definition of done establishes a two-way contract between the team and product owner:

• The product owner take accountability (with the support of the team) for ensuring that stories meet the Definition of Ready before being brought to sprint planning.
• The team takes accountability (with the support of the product owner) for ensuring that stories meet the Definition of Done before being reported as complete.

The instant benefit most teams will observe is both shortening the sprint planning meeting and enabling it to move focus away from “what will be done” to “how they will work together to do it”, and their ability to hit sprint goals will also increase significantly.

The “Next Sprint” Kanban

Story detail should leverage the law of the last responsible moment. We want it neither too early nor too late. My encouragement is to go no deeper than a user-voice form version of the story until the sprint before it is due to play.

Each sprint thus has a dual purpose. Complete the current sprint’s committed stories and flesh out the next sprint’s stories to meet the definition of ready. The first ingredient in doing so is to introduce the “Next Sprint Kanban” to visually manage this journey.

The board illustrated below was from a high assurance environment, where acceptance tests were detailed in the “Specifying” state, then stories were sent off to legal and risk in the “sign-off” state prior to hitting “Ready”.

Figure 1 - Team Aliens: A slightly different approach to visualizing next sprint preparation and a helping hand from Dilbert

Specification Workshops

“Specification by Example” is a great way to flesh out a story. Whilst there are whole books written on the concept (my favourite is definitely Gojko Adzic’s), I have found 3 keys to success:

1. Put them on cadence. Two-three 1-hour sessions per week will usually feed a team pretty well. Scheduling them straight after standup is great as you can use the standup to organise who (whole team or designated amigos) will participate.
2. Don’t produce polished detail, your focus is shared context. Use a whiteboard (preferably in the team area to allow for osmotic communication) and lots of photos as you explore to keep the pace moving and energy up. Word-smithing can be done either solo or by a pair (Product Owner/Tester works well) as followup.
3. The Product Owner needs to order and do some pre-thinking on the stories both to help them identify any subject matter experts or other stakeholders who might need to be involved and to assist the team in identifying appropriate amigos to participate. 

Story Splitting

Good backlogs are, of course, iceberg shaped. As Jeff Patton puts it so eloquently “stories are like cheese, best sliced fresh”. Story splitting will tend to occur naturally as a by-product of user-voice-form workshops and specification workshops. Whatever you do, don’t bury yourself in deep story hierarchies. One layer is good. “Here is my feature, and here are the stories that represent it”. When you split a story, tear up the original and replace it with the newly identified split stories.

What about Kanban?

Everything in this article works as well for a Kanban team as a Scrum team. In fact, I find that the more mature a team becomes in applying these practices the more it moves towards operating in flow with Kanban and leaving Scrum behind. Adaptation is simple – instead of thinking about “next 3 sprints” or “next Sprint”, apply WIP limits to identify the optimal amount of detailed story inventory to hold.

Want a supercharged ART? Don't settle for a Proxy Product Manager!

In a recent SPC class, we wound up in a very interesting discussion about the role of the RTE and the potential need for multiple RTE’s. Given that in our very first Release Train we had employed a “paired RTE” approach (described here by my colleague Em Campbell-Pretty), we had a fairly public opening position on the discussion. I have a client who has a rotational RTE system where each train has 2 RTE’s. One leads execution of the current PI, and the other focuses on preparation for the next. We’ve also seen and heard of numerous other variations. As the discussion progressed, something crystallized for me. In every single case where it’s been necessary, the Product Management function has either been weak/uncommitted or fulfilled in proxy by the IT organisation!

One of the great strengths of +Dean Leffingwell’s approach to defining SAFe has been his pragmatism. One example of this has been his historical approach to defining the type of people (traditional role descriptions) who might fulfill a SAFe role. As with the entire framework, he distills and documents ‘observed patterns’ rather than theory. I vividly remember a moment of shock and horror when I saw that he had listed “BA’s” as potential product managers. Whilst having acknowledged the occasional need to utilise “IT proxy” product owners, the notion of a BA as Product Manager triggered the following email:

Hi Dean,

I'm teaching an SPC and just had the product manager slide onscreen and someone in the audience pulled up the guidance article and said this could be a BA.

After I fell off my chair I suggested someone must have applied the content to the wrong article (ie meant product owner). Are you able to confirm I was right and someone hasn't started smoking strange drugs?

In typical Dean style he reminded me that many organisations have extremely senior strategic BA’s who could well fulfill the role – which got me thinking about a couple of BCG BA’s I had worked with and resulted in a humble apology.

The drawback, however, is that where Dean describes something that “can work in particular contexts”, it is all too common for organisations to interpret the guidance in unfortunate fashions – in this case implicit license to put an IT person in the role. This likelihood is inflated given that most large IT organisations have formed a “wedge division” of “business-facing IT” who act as interpreters and demand managers. The value proposition of such an organisation is threatened by the direct connection between business and developers underpinning agile and it desperately seeks survival .. “surely we are the logical product managers and owners!”

What Dean is looking for is someone who can fulfill the responsibilities and accountabilities of the role. So, what are they? A Product Manager is a person entrusted by the organisation with identifying the best mix of features and steering the optimal economic trade-offs between them to maximise the ROI on an investment of somewhere between $10M and $30M per year.

In recent months I’ve been fortunate enough to launch two Release Trains with not just exceptionally strong co-located business Product Managers but also dedicated co-located business Product Owners for every team. In both cases, they have matured further in a single PI than I have seen in many others across the course of 18 months. Following are some of my thoughts on the key differences:

• Agile is about eliminating the concept of “business and IT”. It’s about working together on a shared mission. It’s not about something “IT does to the business”. Proxies simply maintain the status quo wearing a slightly different disguise.
• The container of the system shapes the system being optimised. As long as the Release Train contains only IT, it will suffer from local optimisation with the relevant area of the business forming a separate system also locally optimising.
• Business people come with business networks. Whilst a short-lived team can source a product owner with deep domain knowledge, a long-lived team will over time work on features covering many domains – to survive the product manager and owners need to know how to bring the right subject matter experts to the table to provide the deep domain knowledge. This is far easier when you’re accessing your mobile phone contact list than researching an org chart!
• Business Product Managers/Owners know how to get the right people to the System Demos and demonstrate in business language about business outcomes being achieved.
• Business leaders bring more to the table than just content authority. They’ve also often received far more development in people leadership than their IT counterparts. Watching somebody bring their call centre team management experience to the table with dev teams is simply amazing. 
• Proxies will be proxies. They will naturally preserve their value proposition by acting as translators rather than connectors. 
• It’s very different when a business leader elects to defer something than when an IT leader asks a business leader to defer something!

Chatting to the executive sponsor during the second PI planning event for one of these trains recently, he shared that one of the things that particularly excited him was watching his business teams reach insights and form alignment at a business process level as they collaborated with the dev teams and their product owners in breaking down their features. He had a grin from ear to ear, but it wasn’t quite as big as the grin I was wearing the night before when I was forwarded an email from another train. It contained the following story:

Once upon a time there was a new Agile Release Train (ART) that had just finished its third sprint. Everyone was amazed at the velocity the teams had achieved. But at the retrospective 2 things became clear:

(1) the teams had worked long hours and many nights to achieve a higher velocity to overcome what they saw as a hump necessary to meet the desired business date for production after 2 more sprints.

(2) the teams were doing "wagile", coding in week 1, then testing in week 2.
The Product Manager thanked the team for their extra efforts, but told them, and - importantly - all the attendees at the showcase, that the velocity achieved was not sustainable, and long days and nights were not to be repeated.

The ART then reviewed the way the teams were working, and decided that extra attention needed to be paid to the adoption of Test Driven Development (TDD). The coach also refreshed the teams on how to conduct sprint planning for sustainable pace.

The Product Manager then told the teams to take as long as necessary to plan for the next sprint, including how to adopt TDD. With some further guidance from the Release Train Engineer (RTE) and Systems Team, the teams re-planned how they would work, as well as setting a more sustainable velocity target for sprint 4.

After I shot an email to the Product Manager saying “hey, can I please quote your story”, she regretfully informed me that she hadn’t been the author but had the following to add:

It was a tough decision knowing that maximum capability in the short term is what senior management are looking for, but also being aware the greater value lay in ensuring the team had the time and space to embed the practices and achieve a sustainable long term velocity and you know the saying, short term pain, long term gain.

On a closing note, my few weeks of pondering the topic have left me with a realization. We obsess about the critical role of the Release Train Engineer. At every gathering of SAFe people, discussions center around how to find, retain and avoid burning out great RTE’s. I think perhaps we’re guilty of spending too much effort on finding and growing RTE’s and not enough on Product Managers. In fact, I’d go so far as to say that in pursuit of great business outcomes and a thriving ART a great Product Manager can cover for a weak RTE far better than a great RTE can compensate for a weak Product Manager!