SPaMCAST 311 – Backlog Grooming, Software Sensei, Containment-Viruses and Software

http://www.spamcast.net

Listen to SPaMCAST 311 now!

SPaMCAST 311 features our essay on backlog grooming. Backlog grooming is an important technique that can be used in any Agile or Lean methodology. At one point the need for backlog grooming was debated, however most practitioners now find the practice useful. The simplest definition of backlog grooming is the preparation of the user stories or requirements to ensure they are ready to be worked on. The act of grooming and preparation can cover a wide range of specific activities and can be performed at any time.

We also have a new installment of Kim Pries’s Software Sensei column.  What is the relationship between the containment of diseases and bad software?  Kim makes the case that the process for dealing both are related.

The Essay begins

Backlog grooming is an important technique that can be used in any Agile or Lean methodology. At one point the need for backlog grooming was debated, however most practitioners now find the practice useful. The simplest definition of backlog grooming is the preparation of the user stories or requirements to ensure they are ready to be worked on. The act of grooming and preparation can cover a wide range of specific activities and can be performed at any time (although some times are better than others).

Listen to the rest now!

Next

SPaMCAST 312 features our interview with Alex Neginsky.  Alex is a real practitioner in a real company that has really applied Agile.  Almost everyone finds their own path with Agile.  Alex has not only found his path but has gotten it right and is willing to share!

Upcoming Events

DCG Webinars:

Agile Risk Management – It Is Still Important! October 24, 2014 11:230 EDT

Has the adoption of Agile techniques magically erased risk from software projects? Or, have we just changed how we recognize and manage risk?  Or, more frighteningly, by changing the project environment through adopting Agile techniques, have we tricked ourselves into thinking that risk has been abolished?

Upcoming Conferences:

I will be presenting at the North East Quality Council 60th Conference October 21^st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

Team Backlogs

If it isn’t on the list, it won’t get done.

The team backlog is comprised of everything a team might get done because if it is not on the list, it can’t be prioritized and taken into a sprint. Simply put, if it isn’t on the list there is no chance of it will get done. The attributes of the team backlog are:

1. The backlog includes all potential work items of the team. Work items will include user stories, non-functional requirements, technical items, architectural requirements, issues and risks. Note: All of these can use the user story construct for communication and presentation.
2. Backlog items represent possibilities. Until the team’s product owner prioritizes an item and the team accepts the item into a sprint, it is merely an opportunity that may get done.
3. Backlog items should be estimated. An estimate reflects the level of effort required to complete the work item based the definition of done and the work items acceptance criteria. Until it si accepted into the sprint, having an estimate is not a sign that the work item has been committed to be delivered.
4. The product owner owns the backlog. The product owner prioritizes that backlog therefore controls what the team works on (product owner is a member of the team). In programs, the product owner helps to channel the programs priorities.
5. The backlog is groomed. Grooming includes ensuring that backlog items are:
   • Well formed,
   • Understood,
   • Estimated,
   • Prioritized, and
   • When necessary removed.

Disclaimer: I am a list person. I have lots of them. I have not descended into lists of lists, albeit I do have a folder in Evernote of lists. Backlogs are the queue of work that a team will draw from. Backlogs, like any list, can feel like they are the end in their own right; almost a form of tyranny. I heard it said, “What is the reward for completing a user story? Another user story.” The backlog can seem relentless. However grooming, prioritization and sprint planning ensures that the team works on what is important and valuable. The backlog is merely a tool to make sure nothing is inadvertently forgotten or ignored.

 

Distributed Agile: Backlog Grooming Meetings

Understanding how a story or a group of stories fits into the big picture is sometime like reading a single line of Shakespeare and trying to develop the plot for the entire play.

There are two reasons to hold backlog grooming meetings. The first is to make sprint planning more efficient and effective. The second reason is to make sure you understand your backlog. When teams don’t spend the time needed to groom the backlog, planning meetings can be very tense and extend for hours . . . and hours. Backlog grooming sessions can be whole team activities (rare) or sub-team activities (more common). The most common technique used to generate a sub-team for grooming is the Three Amigos (or some variant). The tallest hurdle all distributed teams face is ensuring effective communications, followed quickly by staying focused on the task at hand. Many of the same techniques we discussed for sprint planning in distributed teams will be effective, however, backlog grooming has a few unique twists.

 

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.

 

Backlog Grooming Revisited: Formal Grooming Meeting Checklist

Hone the backlog!

In Backlog Grooming Revisited: What, When and How Much we described backlog grooming as an important technique to ensure stories were well formed, the right size and had acceptance criteria. While most formal backlog grooming sessions have their own specific agenda and cadence, I have found that these are the typical set of tasks.

Formal Grooming “Things to Cover” Checklist

• Break Stories Down: Large stories or epics need to be broken down into smaller stories (each delivering working software – Rule 1). When a time-boxed Agile methodology is used, a story must be able to be completed during the time box.  For example if Scrum is being used, a story must be able to be completed during the sprint. A rule of thumb that I use is that the story should be able to be completed 2 or 3 days of effort if it was the only thing on the team’s plate. One reason small stories are better is due to the “stuff happens syndrome.” If a small story gets stuck (something goes wrong) other stories can be substituted and completed ensuring that progress continues. Alternately, if the sprint backlog is just a few larger stories and anything goes wrong with one it is unlikely that a new item can be substituted and completed maintaining the anticipated rate of progress.
• Hone the Stories: During the grooming session the participants should review how the story is worded.  Make sure it makes sense and that it conveys what is really needed. If the story is not understandable or is incorrect, what gets built will not be what anyone wants.
• Add Acceptance Criteria (if missing): Acceptance criteria expresses how the team will understand if they have met the story’s business need. The acceptance criteria, not only provides a set of test cases, but also provides additional definition to the user story.
• Add User Stories (if needed): New stories can come from many angles.  As stories are broken down new stories will be naturally created.  The process of grooming generates a significant level of data sharing which will cause the participants to discover new stories.  New stories need to be added to the backlog.
• Initial Estimates: The grooming participants should take an initial cut at an estimate for the story.  I generally ask the participants to take the first cut at size either in story points or quick and early function points. The initial size gives the product owner information that can help with prioritization of work for the next sprint.
• Educate: Data sharing, discussion and communication provide a platform for the participants in the grooming session to gain an understanding not only of the stories being discussed but also the direction of the project. The knowledge that the grooming session participants gain can later be communicated to the larger team so that everyone’s knowledge base is enhanced.

User stories are the currency of an Agile project. Grooming sessions are an important tool for ensuring the stories are ready and that participants in the grooming session have a deep understanding of the work they about to plan and accept into a sprint.

 

Backlog Refinement Revisited: Three Rules

Break the rules at your own peril.

I am not really a big rule guy, I would rather think of most structures as a guideline. However, sometimes there are some lines that shouldn’t be crossed.  There are three rules that everyone involved in backlog refinement must remember.  These rules are broken at your peril!

1. Rule One (originally described in Splitting User Stories: Patterns): Each story must deliver functionality that is potentially implementable. If a story needs to be split or refined, think slice rather than phase or layer. Each story should represent a thin slice of on an onion starting at the outer layer cutting to the core rather than an individual layer.
2. Rule Two: All formal refinement sessions need to have a clear measurable goal. A goal provides focus for the refinement exercise and provides bounds in much the same manner as an agenda does in a standard meeting. Participants should know the goal for the session (e.g. today we focus on stories supporting the theme for the next sprint) when the session is scheduled so that they can prepare. For example, when I participate in refinement sessions, I try to review the stories that will be discussed so I am not participating to generate questions, but rather participating to generate understanding.
3. Rule Three: While most Agile exercises include the whole team, participation in a refinement session should be limited. I use the Three Amigos technique to ensure a crosssection that includes a tester, product owner or business analyst and developer. refinement sessions are working sessions focused on making sure stories are understood, properly formed and have initial acceptance criteria. The larger the number of people involved in a meeting, the larger the amount of time that will be spent developing a consensus that will be revisited during sprint planning.

When scheduling a refinement session remember the three rules.  First and foremost, all stories need to deliver value. If a story does not deliver value, consider jettisoning the story. If you are going to schedule a session make sure you have a goal.  Just like the relationship between a meeting and an agenda (no agenda, no meeting), if you don’t have a goal for your session generate a one or reschedule the session. Finally, inviting everyone involved in the project (and a few extra subject matter experts for good measure) is a recipe for death by talking.  Constrain the session to the absolute minimum number of participants. User story refinement is important, don’t mess it up!  If you have to break the rules  . . . well just don’t.

 

Backlog Grooming Revisited: What, When and How Much

Periodic grooming keeps the number of knots down!

Backlog grooming is an important technique that can be used in any Agile or Lean methodology. At one point the need for backlog grooming was debated, however most practitioners now find the practice useful. The simplest definition of backlog grooming is the preparation of the user stories or requirements to ensure they are ready to be worked on. The act of grooming and preparation can cover a wide range of specific activities and can be performed at any time (although some times are better than others).

In Agile projects, the backlog is a dynamic representation of business and technical needs. Backlogs can be the expressed needs of a single project or the long term list of needs for an application that will be delivered over many projects. In many organizations anyone (business analysts, developers, users, customers and other stakeholders) can add items to backlog. Given the wide variety of uses and sources of the backlog, grooming is a critical process. Grooming ensures that each story is understood and qualified for inclusion on the backlog. The grooming process reviews how a story is constructed and makes sure that it is properly formed. Grooming also enforces prioritization of the backlog. If a story is going to be worked on soon, the process helps to make sure it is granular enough to be incorporated into a sprint.

In most Scrum-based projects that are past the initial backlog formation, backlog grooming is preformed formally as a periodic event held a few days before the sprint planning meeting. Informally, backlog grooming can (and does) occur during any discussion of the backlog items. In Kanban implementations, backlog grooming is more of a continuous event. Grooming occurs as the immediate backlog (the immediate backlog are the items that will be worked on as soon as capacity is available) is replenished so that the team does not run out of work that is ready to be pulled onto the board.

As the backlog is created, initially the process of grooming often requires a significant amount of effort in order to establish an initial understanding and prioritization. Once established, formal backlog planning becomes less of a burden. Mike Cohn suggests that backlog grooming can consume 5 – 10% of the effort in each sprint. My observations of Agile teams (both Scrum and Kanban) that are past startup do not require that much effort for formal grooming activities, however the amount of formal (and informal if that were measurable) is not insignificant and is variable.

Whether backlog grooming is practiced as an event or as a continuous process, the goal of the activity is to make sure that the team has a list of well-formed stories in priority order ready to be worked on. Grooming does not replace planning, but is a predecessor. However, the process is not free. Effort is needed to perform backlog grooming.  The amount of effort depends on the state of the backlog and where you are in the project life cycle, however grooming pays off. Groomed stories can be more easily planned (more information on sprint planning), accepted in to the sprint and then accomplished.