Backlog Grooming Revisited: Six Governance Principles

Use principles to guard the projects value.

To some, adding a formal meeting to your project calendar for backlog grooming smacks of heavy methodologies. It is as if adding a standing meeting, onE just before a sprint begins to review and hone the backlog will unbalance Agile as we know it. I have heard Alistair Cockburn suggest than anything outside of the original definition of Scrum represented barnacles (barnacles grow on the hulls of ships and cause extra drag).  I believe Alistair’s the comment was meant to cautionary, and any step added to the process better deliver more value than it costs in process drag. Regardless of how it was meant, let’s take the cautions to heart and make sure we do no harm. When we add a backlog grooming session there are six governance principles to make sure we don’t reduce the amount of value the project can deliver.

• Future Looking: Backlog grooming sessions are about the future. In a grooming session, participants are exploring where the project will be going in the relatively short-term future.  What the session is not is a platform to whine about or rehash the past. Use a coach to help set the tone for grooming sessions when they are introduced or if problems start to crop up.
• Not Final Plans: Decisions made in backlog grooming sessions, estimates for example, are starting points for discussion in sprint planning.  The grooming session does not reflect a new form of hierarchy that dictates direction and how work will be done, but rather reflects a need to make sure everything is ready to maximize the time available to the team. Grooming sessions that deliver final plans for team rubber-stamping have missed the concept.
• Identify Emerging Risks: Risk and risk management activities should be incorporated into the day-to-day activity of the team (or teams), however the grooming session provides a time to discuss whether there any emerging risks, whether there are new stories that are needed to address risk and whether any stories previously identified to address risk need to be re-prioritized.
• Grooming Sessions Require Homework: Participants need to review that they think will be covered during grooming session before they walk in the door.
• Time Box:  Grooming sessions should be time-boxed, just like every activity in Agile.  I have found that once a project has reached a steady state, the formal grooming session will need 30 minutes each week of sprint duration (a grooming session for a two week sprint should be one hour). Grooming sessions for a brand new project may take longer and grooming sessions for project nearing completion may need less.
• Retrospectives: Just like any process in Agile the participants in the grooming session need reflect on what was accomplished, how it was accomplished and how it can be done better.

Backlog grooming sessions help get stories ready for the team to plan. As we have noted stories are honed, split, prioritized, and risk stories reviewed so that the sprint planning session is effective and efficient. The process sounds nearly too good to be true, which means that it probably is not true unless we remind ourselves of the principles that will govern backlog grooming.

 

Scrum . . . A Simple Framework: Barnacles

Barnacles attach to ships and add drag

In earlier entries of the Daily Process Thoughts, I believe we have established that basic Scrum process can be defined using three roles, five events and three artifacts. This is the Scrum canon, much like the canon of stories that make up the Sherlock Holmes series. Many organizations and consultants have added practices to Scrum in order to meet specific needs (if those needs are real or perceived is an open question).  At the Scrum Gathering in Las Vegas in 2013, Dr. Alistair Cockburn called these additions barnacles; Ken Schwaber has written extensively about “Scrum buts. . .” and “Scrum ands. . .”. Barnacles grow on the hull of ships and create drag, slowing the ship or requiring greater energy to drive the same distance. However for all of the downsides of a barnacles they serve a purpose, deliver a benefit, or they would not exist in nature.  The additions to Scrum must compete and deliver value or they will be swept aside.  Several of the more common barnacles are related to defining and estimating work. They include:

• User Stories, phrased in the now classic “persona, goal, benefit” format, are an addition to the canon of Scrum.  User stories provide a disciplined framework for describing units of work, which improves communication.
• Story Cards, which generally include the user story, acceptance criteria, size and other ancillary pieces of information, provide a means to the organize units of work a team will be working on.  Organization of information provides a means of visualizing gaps and keeping track of work items so they can be communicated (and in my case, so they don’t get lost).
• Story Points, are a representation of the size of a user story or any unit of work based on the collective understanding of the team that is being tasked to deliver the work.  The use of story points provides a team with a consistent scale that helps team members communicate about their perception of size.
• Planning poker, a variant of the Delphi estimation process, acts as mechanism to structure the discussion of size and estimation within Agile teams to increase communication, ensure all relevant voices are heard and to control paralysis by filibuster.

Add to the potential additions technical practices like Test Driven Development, Behavior Driven Development, Continuous Builds and hybrids like Scrumban and the number of potential barnacles can grow quite large.  That is the nature of a framework.  Techniques, practices and processes are bolted on to the framework first to see if they improve performance.  As practitioners and methodologists we must insure that only those that provide tangible, demonstrable value are allowed to stay bolted.  Remember that each organization and team may require more or less barnacles to be effective.  Like the Sherlock Holmes stories, others have extended the canon with their own stories, practices and process.  Some are valuable and find traction, while others are experiments that have run their course.

 

Agile Story Mapping: Building An Agile Story Map

The map of the Great Wall is an information radiator.

One of the most powerful concepts championed by the Agile movement has been the use of information radiators as communication vehicles.   Alistair Cockburn defines information radiators as “a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions.” The goal of these tools is to increase access to information through transparency. Agile Story Maps are information radiators. The goal of a Story Map is to present the big picture of the project in assessable manner for everyone on the team. The Story Map’s ease-of-use and transparency increase the likelihood of collaboration and feedback within the team. The Story Map is also a tool to visually plan releases. The first step is to create an Agile Story Map.

Agile Story Map Exhibit Version 2

Here’s the process (assuming that you’re not starting with an existing backlog).

Story Generation/Grouping

1. Gather a cross disciplinary team of 3-7 people that understand the purpose of the product. The team should include a mix of business and technical perspectives. The team size should constrained because as it grows the amount of discussion will increase faster than value.
2. Have the team identify the marketable features of the project/application.  I use silent brainstorming; each person silently writes down one marketable feature per sticky note. Once everyone has finished writing their post-its, have each person read their sticky note aloud and place them on the table in front of the group. If anyone has duplicates they should be removed at this point.
3. Next have the team group/rearrange the sticky notes without talking (affinity diagramming). Move things that are similar to each other closer to each other and things that are dissimilar to each other should be moved farther apart.
4. Name each group and place another color of sticky with that name above of the group. These are the Epics. The facilitator should lead this this step interactively.
5. Arrange the groups left to right in the order that they would naturally occur (user visible functionality or batch).
6. Review/walk the skeleton (term coined by Jeff Patton) to validate completeness in terms of user tasks or activities. The goal of this process is to identify holes in the story map based on the knowledge the team currently has available.
7. Break each epic or user task down into more detailed user stories or activities (I use a rule of thumb to break that stories should be broken into thin slices that can be completed during a sprint).

 Prioritization: There are several strategies for prioritization.

1. Business Value – assign business value to each story in the map. The Product Owner generally leads this effort. Prioritize the highest value first.
2. Risk and Complexity – assign a level of risk and complexity for each story.  The technical team members will generally have significant input into this discussion. Prioritize risk and complexity higher.
3. Perceived Dependencies – Tweak prioritization to reflect dependencies. The technical team members will generally have significant input into this discussion
4. Combination – Combine all three (my favorite approach).  Generally I prioritize by risk then value and then dependencies.  This engages the whole team in the discussion and front loads risk as a mitigation technique.

Based on the prioritization strategy, review each user story and assign it a priority.  I use the nomenclature of dollar value and a high, medium or low risk/complexity (i.e. $4000,H).  It is very difficult to precisely define the business value of each story, the actual dollar value is less important than assign a relative value for each story.  Knowing the relative value will provide the team with an understanding of which stories will provide more value. After assigning a value to all stories, sort each list from highest to lowest and roughly aligning stories of similar value.  When two stories have the same or nearly the same value they will be placed together (example in Column three in the exhibit above).

Story mapping is a relatively simple process that organizes the backlog. The story map is an Agile information radiator because it provides the team and stakeholders with information with them having to ask or dig. An Agile Story Map provides the big picture of the application and the priority of each of the stories.  Tomorrow we will use the prioritized map to generate a release plan.

 

Commitment and Learn Early/Fail Early

Getting to graduation reflects commitment and learning.

Every project is a learning activity, whether the project is a simple maintenance activity or the most complex development project. In every case we are looking for a means of solving a business problem. Alistair Cockburn in his keynote at the Scrum Gathering in Las Vegas, 2013 rephrased the oft repeated Agile and lean start-up catch phrase, “fail early, fail fast” as “learn early, learn fast.” Agile attacks the concept of learning early by breaking work into small components and having the team commit to tackling those components a piece at a time. The benefit is derived by getting to functionality early rather than waiting until late in a project to know whether the right functionality has been developed, or even, if it can be developed. The earlier we answer the questions we have about how and what we are doing the better. The Agile techniques of breaking work into small components, then tackling them in a manner that returns the greatest amount of early learning is a risk reduction mechanism.

In Learn Early, Learn Often” Takes Us Beyond Risk Reduction^[1], Alistair Cockburn suggests that all projects seek to answer four questions.

• How can we learn to build what is desired?
• How can we learn how much it will cost (time, money, people)?
• How can we accelerate the team learning how to work together?
• How soon can we correct the mistaken assumptions in the design?

Agile provides us with a set of mechanisms to develop answers to these four questions early in the project. Story writing and backlog grooming takes larger components and breaks them into pieces of work that can be taken into a sprint and completed. This supports getting to done and then to feedback as a tool for learning.  The act of committing to the work, saying what you are going to do and then doing what you said, provides both transparency and a feedback mechanism. Transparency lets stakeholders understand how the team is attacking the work to solve the business problem and at the same time how the team is progressing. The act of delivering and demonstrating/reviewing work at the end of every sprint generates feedback which can be translated into knowledge and learning.

Agile supports a culture where commitment and learning not only can co-exist but actually work best if they do co-exist. If we view every project as a potential risk that can only be mitigated when the right business value is delivered, then each project represents a set of decision points where feedback is required to guide the work towards value. The impact to overall project risk reduction based on learning early in the project what will work and what won’t work or what the real business needs are, will increase the potential for the project to succeed. Committing to deliver complete units of work at the end of every sprint puts the team and the stakeholders in position to understand unknowns that cannot be exposed without hands-on exploration. The combination of commitment and learning early lowers the risk of delivering and then being surprised.

---

^[1] How “Learn Early, Learn Often” Takes Us Beyond Risk Reduction , July 3, 2013, http://alistair.cockburn.us/Disciplined+Learning

 

Methodologies

What is the difference between a software development framework and a methodology?  We define a framework as a scaffold for an approach to developing, maintaining and enhancing software. Agile is a framework. A methodology is the structure, a set of principles and values, tools and practices which can be used to guide processes to develop, maintain and/or enhance software. Extreme Programming (xP) is an Agile Methodology. Methodologies use frameworks as a roadmap and provide the tools to make frameworks work.

Scrum is an example of a framework. In his recent keynote at the Scrum Gathering in Las Vegas, Dr. Cockburn suggested that Scrum could be defined in “five sentences and that everything else are just barnacles.” Even if we decide that the statement was hyperbole, the framework describes three roles, four meetings, and three artifacts. Scrum does not specify how the meetings or artifacts are to be created or how they should look, but they must be done within the values and principles of the Agile Manifesto.  xP is a methodology that includes a framework featuring feedback and planning loops, principles such as test first, practices such as pair programing and tool supported practices such as continuous integration.  A methodology specifies not only how the development team should act, but also a specific structure and rules to guide behavior.

A framework is not a methodology, however every methodology represents an implementation path for a framework.  Methodologies tell you how to achieve the structure, principles and values that a framework describes.  The distinction between framework and methodology might sound semantic, however understanding the distinction is important to managing exceptions when implementing changes using either a framework or methodology. Methodologies describe how the work is to be accomplished, rather than just the outline of what is to be done. Therefore methodologies are by definition prescriptive, which needs to be communicated and managed during implementation.