View on GitHub

playbook

Samples of content written by Phil Rogers that is not published on my blog

Playbook

What you’ll find here are samples of content I’ve written that is not published on my blog. I’m using the term “Playbook” to refer to this whole batch of content because it’s one way of referring to a set of guidelines that can be helpful in many different organizational contexts.

Quick Start Guides

The Quick Start Guides consist of brief summaries of what I’ve found to be effective when working with teams, and which are likely to be particularly helpful to anyone who would like some general guidelines, which are not intended to be prescriptive, but which can serve as a baseline for any team to work from. Most of the Quick Start Guides focus on Scrum-related topics (Scrum Events). The rest of them cover other areas that we often encounter as facilitators.

Scrum Topics:

Additional Topics:

Backlog Refinement Quick Start Guide

Introductory Note: Backlog Refinement (also known as Backlog Grooming) is an activity that is not part of the Scrum Guide. However, the practice of Backlog Refinement is so common among Scrum teams that some practitioners consider it a Generally Accepted Scrum Practice (GASP).

Definition

Backlog Refinement is an ongoing process of readying user stories for upcoming iterations (Sprints). There are two main aspects of Backlog Refinement:

Frequency

Note: Some teams choose to have Backlog Refinement sessions more than once per Sprint.

Duration

Teams should strive to complete Backlog Refinement for a two-week Sprint in an hour or less. It is more likely for teams to be able to complete Backlog Refinement in a reasonably short amount of time when stories are well-articulated well before the Backlog Refinement session starts. (See also the Writing Well-Articulated User Stories Quick Start Guide.)

Participants, Inputs, Outputs

Activities

Activities during Backlog Refinement typically include:

Note: See also Backlog Refinement and Sprint Planning: Similarities and Differences

Daily Scrum Quick Start Guide

Definition

The Daily Scrum (aka Daily Standup) is the opportunity for a Development Team to make sure they are in alignment every day via a short, focused conversation. The main things that happen during the Daily Scrum:

Frequency

Once every day (generally with the exception of the first day of the Sprint)

Duration

The duration of a Daily Scrum is intended to be no longer than 15 minutes.

Participants, Inputs, Outputs

(+) Participants are listed in order of importance: The Daily Scrum is for the Development Team, and thus, the meeting belongs to them. A Scrum Master is often present as a facilitator. However, it is also common for different members of the team to take turns acting as the facilitator. It can also be helpful for the Product Owner to be present, to clarify any product-related questions that might arise.

Activities

An example of a “Daily Standup Routine” is as follows:

Note: H/T to Jimmy Janlén for the “Daily Standup Routine” idea, in his book Toolbox for the Agile Coach: Visualization Examples.

Note 2: See also Daily Standup Patterns 

Sprint Planning Quick Start Guide

Definition

Sprint Planning is a meeting that focuses on making sure there is complete clarity on what the team plans to work on during a Sprint that is about to start. There are several key aspects of Sprint Planning:

Frequency

Once per sprint (the first day of the Sprint)

Duration

Provided that Backlog Refinement has been done before Sprint Planning begins, many teams are able to complete Sprint Planning in an hour or less. The higher the degree of uncertainty about the work that is to be done during the Sprint, the greater the likelihood that Sprint Planning could take more than one hour.

Participants, Inputs, Outputs

Activities

Definition

The Sprint Retrospective is an opportunity for a team to have an open and honest conversation, which typically focuses on the work the team did during a Sprint that is coming to a close. The Sprint Retrospective is the team-level enabler of Kaizen, or Continuous Improvement.

Frequency

Once per sprint (the last day of the Sprint)

Duration

Team context plays a significant role in the duration of a Sprint Retrospective. For teams that are relatively new to working with each other, or that find themselves in a situation where they need to surface and overcome significant challenges, a miminum of one hour is likely to be neeed. Other teams may find that 30 minutes is sufficient for their Sprint Retrospective.

Participants, Inputs, Outputs

(+) Some Agile practitioners suggest that it is unnecessary (or even undesirable) for a Product Owner to attend a Sprint Retrospective. Given the importance of the relationship between and among the Product Owner, the Scrum Master, and the Development Team, as a general practice, enabling the Product Owner to be part of the Retrospective conversation is likely to help that team continuously improve.

(++) In the interest of psychological safety, it is a standard practice that ONLY the members of the Development Team, the Scrum Master, and the Product Owner attend Sprint Retrospectives.

(+++) Teams often discuss a great many things during the Sprint Retrospective, however, what the team talks about during the Sprint Retrospective is considered confidential, and is not shared with anyone who was not present during the conversation, unless all members of the team agree to share one or more parts of the conversation. The chief exception: any actionable steps that the team identifies to help them improve, which typically are made visible to others.

Activities

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

(+) The universe of potential approaches for retrospective facilitation is vast. Teams are far more likely to get value out of Sprint Retrospectives over time if and when the questions that are asked and the way in which they are framed and answered varies from one Sprint to another.  

Sprint Review Quick Start Guide

Definition

The Sprint Review is a meeting that focuses on making sure there is complete clarity on what a team finished during a Sprint, and what they expect to work on next. There are several key aspects of the Sprint Review:

Frequency

Duration

Because there is the potential for significant variation in format, e.g., single-team Sprint Review, or multiple team Sprint Review, the length of such sessions can vary significantly, from as little as 30 minutes for a single team, to one or more hours for multiple teams.

Participants, Inputs, Outputs

Activities

Story Splitting Quick Start Guide

Story Splitting Steps

  1. Prepare the story to be split; Does the story have all of the INVEST attributes, with the exception of small? See Story Attributes for a refresher.) Yes/No
  2. Based on its current size, is the story too large to be completed in HALF of the current sprint? Yes/No
    • If Yes, it should be split - continue.
    • If No, make sure there are open questions about the story; no need to go further.
  3. Based on its current size, is the story likely to consume a large amount of the team’s capacity? (That is, completion of a story should not consume more than a small fraction of that team’s capacity for a Sprint) Yes/No
    • If Yes, it should be split
    • If No, there is no need to go further
  4. Apply splitting pattern(s); When considering how to split a story, keep the following two guidelines in mind:
    • Choose a pattern that results in one or more post-split stories that can be deprioritized or even eliminated. Suppose that applying one split pattern exposes low-value functionality and another does not; this may be a sign that application of the latter split conceals waste (i.e., low-value work) inside the post-split stories. Apply the split pattern that makes it possible to deprioritize or eliminate work.
    • Choose a pattern that results in similarly sized post-split stories. If the post-split stories are similarly sized, it makes prioritization easier.

Split Patterns

The split patterns discussed here are:

Workflow Steps Pattern

Suppose that a particular story is based on a well-established workflow. Thus this pattern splits the larger story along the lines of individual steps in the workflow, such as:

Business Rule Variations Pattern

This pattern seeks to separate business rules that are present in a particular story, looking for opportunities to split the story based on differences between /among those business rules. Here are several sample business rules:

Simple/Complex Pattern

With the simple/complex pattern, look for opportunities to modify a story that is very general (which often hides complexity). Attempting to define acceptance criteria for each piece helps to facilitate this process. For example, if there is a story that says …

Might be made more specific in ways such as …

Variations in Data Pattern

In this pattern, the focus shifts to data objects. Work with the team to choose data object options based on user roles and actions. Suppose that there are data objects called Product, Payment, and Receipt. In this instance, the idea would be to focus on specific data types for each object type. So for Product, there might be data types such as Book, DVD, and Gift Card.

You can then work with the Product Owner to identify the data type or types with the highest business value and split the story accordingly. Complexity in a story can come from handling variations in data.

Data Entry Methods Pattern

Complexity sometimes surfaces in the user interface itself. In that case, split the story to build it with the simplest possible UI and then build the more usable or fancier UI. These, of course, aren’t independent—the second story effectively is the original story if you do it first—but it still can be a useful split. Splitting in this way is also one way to think consistently in terms of “what is the simplest thing that would work?”

The story above could be modified to qualify what kind of user input might be needed, as follows:

Defer Performance Pattern

In this pattern, the idea is to look for opportunities to defer work that is making an existing story inordinately large. Trying to achieve a particular performance target via a single story can make it big. It is often best to look at system performance as a global constraint that needs to be addressed more broadly (for instance, as part of the Definition of Done).

Here are some additional examples of “non-functional” requirements that are often best considered separately:

*Note: To be clear, it’s not being suggested that Definition of Done considerations such as those above aree not important; what we’re trying to avoid here is attempting to solve for such things via a single user story.

Operations Pattern

With this pattern, try focusing along the lines of operations and procedures. Some teams might look at this in terms of a CRUD (create-read-update-delete) scenario, such as this:

If the above story is still too big, it could be further split based on CRUD operations like this:

Another general rule of thumb is to watch for generic verbs such as “manage.” For example, if there is a user story which says “as a new student, I want to manage my account…” the word “manage” tends to conceal more specific actions such as “cancel an account,” edit an account,” and so on.

Break Out a Spike Pattern

A story may be large not because it’s necessarily complex, but because the implementation is poorly understood. In this case, no amount of talking about the business part of the story will allow you to break it up. Do a time-boxed spike first to resolve uncertainty around the implementation. Then, you can do the implementation or have a better idea of how to break it up. Suppose that you’re not sure which technical approach you’ll take to implement the following story:

You could instead first start with a spike:

And then go on to implement the story as articulated above (assuming that it is small enough to not require being split first.)

In the “Choose a technology” spike, the acceptance criteria should be questions you need answered. Do just enough investigation to answer the questions and stop; it’s easy to get carried away doing research.

The spike split is the last one because it should be your last resort. You probably know enough to build something. Do that, and you’ll know more. So, make every effort to use one of the previous eight patterns before resorting to the spike pattern.

Evaluate the Split Stories

Here are some questions you need to ask to determine whether the original story is split as well as it can be, and whether the post-split stories need further work:

  1. Are the post-split stories roughly equal in size? Yes/No
    • If No, consider applying a different pattern to split the original story, or choose a pattern with which to split any post-split story that is/are larger than the others
  2. Do each of the post-split stories have all of the INVEST attributes? Yes/No
    • If No, consider applying a different pattern to split the original story, or refactor any of the post-split stories that need rework.
  3. Do any of the post-split stories reveal especially high-value or low-value work? Yes/No
    • If Yes, work with the Product Owner to determine whether the work in a post-split story is: a) higher in relative priority than other post- split stories; and b) necessary (sometimes the exercise of splitting stories reveals work that is not really necessary)

Story Attributes

When writing users stories, strive to make sure that each user story satisfies all of the INVEST attributes, where INVEST stands for:

References

The content in this quick start guide is based on patterns observed and compiled by Richard Lawrence on his blog See also: Invest In Good User Stories  

Writing Well Articulated User Stories Quick Start Guide

It is common for teams to struggle with writing user stories that clearly communicate these things:

Note: There is a common misconception that the sole responsibility for writing user stories rests with a Product Owner (or a proxy for the Product Owner). Although it is common for Product Owners to draft user stories, it is important for team members to be involved with writing and refining user stories, because when the team is engaged in this activity, it improves the likelihood that everyone has the same understanding of what is to be built, why it is to be built, and how we know when it’s done.

Individual sections follow on each of the main components of a well-articulated user story:

Story Title

Just as is the case with other types of titles (aka headlines), a story title should be short, because short statements …

Story Title Format

The following format is recommended for story titles: (role) (action) (context)

For example:

where … (role) = Primary applicant (action) = enters passcode

Note: (role) and (action) are required, whereas (context) is optional in the title. For instance, when there are many user stories with similar titles, the addition of context can help distinguish between them. In the example above, perhaps it will be possible for the user to enter a passcode in different places in the application being built, or perhaps there is more than one kind of passcode. In such cases, adding context could add clarity, such as “Primary applicant enters passcode on (page type), or Primary applicant enters passcode (type of passcode).

Story Description

The canonical format for a story description is as described below. Here are some things to keep in mind when writing the story description. Think in terms of inputs and outputs:

Think in terms of vertical slices:

Think in terms of the smallest number of words that can convey the story intent:

Story Description Format

The canonical format for a story description is

For example:

Story Priority

The priority of a user story is reflected by its relative position in the Product Backlog, and by its relative position in the Sprint Backlog (user stories closest to the top of the list have the highest priority).

It’s not a good use of time to agonize over the relative priority of items well down in the backlog, e.g., whether a user story is priority 50 or 51. It is important to have clarity on the top 10 to 20 items in the backlog, in particular. A decision-making tool that can save time on prioritization is called the Pyramid Backlog, which Jimmy Janlen mentions in his book Toolbox for the Agile Coach: Visualization Examples

Note: The Jira Priority field provides many additional options that can indicate relative importance of any given work item. This quick start guide does not cover usage of the Jira Priority field.

Story Size

When Agile teams estimate size, they employ “relative estimation.” It’s called relative estimation because we focus on the relative size of thing A relative to thing B, thing B relative to thing C, and so on.

Note: In practice, teams that choose to estimate often use T-Shirt sizes to start with, for instance, when doing affinity estimation.

Story Size Format

For teams that use story points to estimate, it is most common to only use numbers that are part of the Fibonnaci Sequence for story point estimates: 1, 2, 3, 5, 8, 13 …

Why use the Fibonacci Sequence?

As anyone who has spent any time building software can attest to, it is a difficult proposition to precisely estimate the size of anything we build, and the larger the size of the batch (be it a feature, or a release), the greater the uncertainty and the risk. (Keeping batch size small helps minimize both complexity and risk.)

It has become popular to use the Fibonacci sequence because doing so can help reinforces the notion that estimates are never exact. For instance, when we consider a user story that has been sized as a 3-point story, and a user story that has been sized as a 5-point story, all we can say with any level of certainty is that based on what we know right now, it will be more work to complete the 5-point story than it will to complete the 3-point story. (By way of comparison, if we are looking at a 3-point story and a 6-point story, it’s more likely we’ll fall into the trap where we assume the 6-point story is exactly twice as big as the 3-point story).

Another appealing aspect of using the Fibonacci sequence is that the bigger the numbers get, the larger the gap between them, which serves as an indicator that uncertainty and risk tend to increase rapidly as work items get larger.

Why estimate at all? (“no estimates”)

There are practitioners in the Lean-Agile community who suggest that spending time on estimation is a form of waste. (In Lean in particular, there is a focus on minimizing, if not getting rid of altogether, any activity that does not deliver business value, and it can be argued that spending time on estimation, especially when teams spend an inordinate amount of time on the activity, is a waste of effort.)

Some people might wonder how teams can forecast when they will finish a particular body of work, if they don’t estimate the relative size of the work items in the backlog. The answer for those teams is often as simple as this: If there is a need to calculate velocity, rather than counting story points (or other units of estimation), simply count the number of finished work items. For instance, if a team finishes 10 stories in Sprint 1, 12 stories in Sprint 2, and 15 stories in Sprint 3, then their velocity is 10, then 12, then 15.

Note: Teams that have success without estimation tend to also be quite good at consistently breaking down work items into reasonably small pieces, where the largest would likely not take more than a few days to complete. In the spirit of Inspect and Adapt, how they estimate, and whether they estimate, can be an area of experimentation for teams.

Story Acceptance Criteria

For any user story to be considered Done, it needs to satisfy its Acceptance Criteria, AND it needs to align with any global provisions that exist in a Definition of Done.

A simple way to articulate the purpose of Acceptance Criteria is this: Acceptance Criteria guide the testing strategy, enabling us to demonstrate (via tests) that the user story achieves what it is intended to achieve.

Note: Acceptance Criteria often do not map directly to a particular field in Jira (depending on how Jira is configured).

A couple of examples of ways to include Acceptance Criteria in Jira include:

Story Acceptance Criteria Format

There are multiple ways to write Acceptance Criteria. Note: For the purposes of this quick start guide, we only describe the “Test that… “ format for Acceptance Criteria, which is among the simplext alternatives in terms of syntax.

Test that …

Here are several examples of tests written in the Test that … format:

Story Technical Approach

In contrast with the story headline and story description, which focus on the who, what, and why, the technical approach (in conjunction with the Acceptance Criteria) focuses on how.

Note: In general, artifacts that fall under the technical approach map to Jira as attachments, links, or Sub-tasks.

Story Technical Approach Format

Because the technical approach can vary significantly, depending on the product, it is difficult to specify a particular format for the story technical approach. Here are some general guidelines:

Note: Jira (and many other tools) support the practice of entering time (typically in hours) associated with tasks. Many Agile practitioners consider the entry of tasks, not to mention the task duration (i.e., “burning down” the hours) as a form of waste. In other words, the most important thing to focus on is task completion, not on spending time specifying that a particular task is half-done about lunch time, and three-quarters done at the end of the work day.