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.
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:
- Backlog Refinement Quick Start Guide
- Daily Scrum Quick Start Guide
- Sprint Planning Quick Start Guide
- Sprint Review Quick Start Guide
- Sprint Retrospective Quick Start Guide
Additional Topics:
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).
Backlog Refinement is an ongoing process of readying user stories for upcoming iterations (Sprints). There are two main aspects of Backlog Refinement:
- Ongoing definition, refinement, clarification, and reprioritization of functionality, often led by Product Managers and Product Owners;
- A collaborative meeting prior to the start of a Sprint to evaluate new information, ensure the next set of stories is ready for development, and reach early consensus on a set of stories to be included in the upcoming Sprint Backlog.
- Once per Sprint (typically mid-Sprint)
Note: Some teams choose to have Backlog Refinement sessions more than once per Sprint.
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 - Product Owner, Scrum Master, Development Team
- Inputs – Primary inputs are the user stories forecasted for the upcoming Sprint, and also some additional stories that might be a good choice for a subsequent Sprint. It is helpful to have more user stories in a ready state than are likely to fit in the next Sprint, so that there is flexibility in case the team identifies a dependency, has new information that could impact priority or effort of one or more stories, or when questions surface that might need to be answered before working on a particular story.
- Outputs - Consensus on a set of prioritized, clearly-defined, independent, small user stories that are framed to generate valuable and demonstrable functionality during an upcoming Sprint.
Activities during Backlog Refinement typically include:
- Review new information learned from the current Sprint
- Discuss Best, Probable, and Worst case Velocities
- Do a checkpoint on current Sprint progress - do we feel we will complete all the work during the Sprint that we thought we would?
- When answering this question, keep sustainable pace in mind
- It is better for the team to realistically assess how things are looking mid-Sprint than it is to wait until the end of the Sprint to make any course corrections that might be needed
- Review and clarify upcoming user stories
- Discuss and agree to Acceptance Criteria to confirm shared understanding Confirm size estimates and slice stories that are too big
- Reminder: Any story that a team thinks will take more than half of a Sprint to complete is too big
- Agree on the plan for the next Sprint
- Based on our velocity prediction and sizing, is this a realistic plan?
- If the answer to the previous question is "no," work to slice stories, and/or swap in smaller stories of similar priority, until the team feels confident in the plan
Note: See also Backlog Refinement and Sprint Planning: Similarities and Differences
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:
- Share knowledge
- Identify opportunities to help another team member
- Identify dependencies/risks
- Agree on next steps for removing roadblocks
Once every day (generally with the exception of the first day of the Sprint)
The duration of a Daily Scrum is intended to be no longer than 15 minutes.
- Participants - Development Team, Scrum Master (or other facilitator), Product Owner +
- Inputs – Primary input is any work for which the workflow state has changed since the last Daily Scrum. Other potential inputs include any anomalies that might have surfaced during testing, changes in priority, or anything else that could impact the work that is planned for the Sprint
- Outputs – Agreement among team members about what to do to address any impediments that have surfaced, and how they can most effectively work together during the next 24 hours to move any in-progress work items to done
(+) 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.
An example of a “Daily Standup Routine” is as follows:
- Start the Call
- Walk the Wall (take a quick look at where things are in the workflow, where the wall can be a physical card wall, or a virtual wall, in Jira, or both)
- Headlines (is there anything particularly urgent that needs to be discussed?)
- Updates (blockers or other information team members would like to mention)
- High Five (just like it sounds, whether physical or virtual ... ;)
- After Party (synonymous with a Parking Lot – a time to have a follow-up conversation, if necessary; in some cases, only a subset of team members may be needed for an After Party).
- Update the board (if the workflow state of any work item was updated during the conversation)
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 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:
- Formulation of/refinement of Sprint Goal(s)
- Discussion about/confirmation of functionality (stories) to be worked on during the Sprint, based on their relative priority
- A deeper dive conversation that can, on some teams, include task decomposition, where the team identifies specific tasks that need to be completed for any given story they are planning to work on
Once per sprint (the first day of the Sprint)
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 - Development Team, Product Owner, Scrum Master
- Inputs – Primary input is a set of well-defined (clearly written, sized, prioritized, with Acceptance Criteria) stories from the previous Backlog Refinement session. Other potential inputs include any changes to priority since the Backlog Refinement session, or unfinished stories from the Sprint that just ended
- Outputs – Sprint Goal(s) and a well-articulated Sprint Backlog
- Start with one or more Sprint Goals (to be revisited at the end of the session)
- Capture any business or technical assumptions that the team is making about the work they plan to do (which can also be a helpful way to make sure no important information was missed during Backlog Refinement)
- Review any other new information which may have surfaced since the previous Backlog Refinement:
- Any changes to prioritization of stories to be worked on next
- Any stories not completed during the Sprint that just ended, which could be worked on during the Sprint that is about to start, depending on their priority
- Review who (if anyone) is going to be out of the office, and for how long
- Surface any dependencies or risks, including who might be the owner(s) for mitigating those dependencies or risks, and what the expected impact could be
- Review and clarify user stories:
- Confirm story wording for clarity Confirm Acceptance Criteria Confirm relative size
- (optional) Task decomposition: Some teams choose to further break each story down into a set of tasks during Sprint Planning, some teams do task decomposition individually (after Sprint Planning is over), and some teams do no task decomposition at all
- The newer the team is to working with each other, the higher the likelihood that task decomposition could be helpful to them
- Many teams that have been working together for a while find that task decomposition is not necessary, especially when those teams are consistent about breaking stories down into reasonably small pieces
- Agree on the plan for the Sprint:
- Based on team capacity, is this a realistic plan?
- Are all dependencies or risks identified, along with any Action Items needed to ensure the dependencies or risks do not become impediments?
- If the answer to either of the previous questions is "no," look for ways to allocate work more evenly among team members, and/or account for what needs to happen to address dependencies or risks
- When the team reaches agreement on the plan, ensure that the physical board (if the team is using one) and Jira are updated accordingly
- Revisit the Sprint Goal(s) and make sure they align with the team's plan for the Sprint
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.
Once per sprint (the last day of the Sprint)
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 - Scrum Master, Product Owner,+, Development Team++
- Input – Primary input is the sum total of the interactions the team had during the Sprint
- Outputs – Clarity about potential changes to the team’s way of working, articulated as one or more actionable steps that the team agrees to which can help them work together as effectively as possible +++
(+) 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.
- The facilitator (who is most often a Scrum Master) sets the stage for the conversation
- The Sprint Retrospective is more likely to be a productive use of time if and when the facilitator has prepared in advance for what activities and what types of conversations are most likely to help the team, based on its particular context
- To establish psychological safety, it is helpful to always keep the “retrospective prime directive,” as articulated by Norm Kerth, in mind:
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.
- With the help of the facilitator, the team reflects back on the Sprint that has just ended. A common set of three areas to talk about are:+
- What went well during the Sprint
- What did not go so well during the Sprint
- What actionable steps can the team potentially take to improve going forward
- It is important to never lose sight of the positive. A good way to help ensure that positive observations are included can be as simple as asking something like “who would like to thank another team member” (or someone external to the team) for something they helped with during the Sprint?”
- The actionable steps that the team agrees to are made available in a visible place, which helps ensure that the team remembers to work together to address those areas of potential improvement
(+) 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.
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:
- An overview of what has changed in the product since the last Sprint Review
- A demonstration of current product functionality
- A preview of what’s coming up next for the team
- Once per sprint (the last day of the Sprint)
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 - Product Managers, Product Owners, Scrum Masters, Development Teams, stakeholders
- Inputs – Primary input is the set of work items that a team completes during a Sprint. Other inputs include any changes to overall vision or priority at the strategic/product level since the last Sprint Review
- Outputs – Clarity about the work the team completed; feedback from stakeholders about the work the team completed; clarity about what the team plans to work on next, taking into account any stakeholder feedback, along with business priorities in general
- Set the stage by painting a general picture about what is different in the product since the last Sprint Review
- Discuss the Sprint Goal(s) and the extent to which the team met the goal(s)
- Demonstrate work that the team completed
- Try to refrain from depicting the work in terms of user story x, user story y (a level of detail which may not be meaningful to some stakeholders)
- Instead, focus on telling a coherent narrative about the current behavior of the product
- Ensure that stakeholders have an opportunity to provide feedback
- (optional) Touch on any challenges the team may have encountered during the Sprint, what the impact of those challenges was, and how the team may have overcome one or more of those challenges
- Recognize the team for the work they did (and also anyone else who might have played a role in helping the team during the Sprint)
- Provide a preview of what’s coming up during the next Sprint
- Be sure to account for any feedback that could affect those plans
- It’s okay to also provide insight into what they team will be focusing on beyond the next Sprint; however, the focus is on what is coming up next
- 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
- If Yes, continue.
- if No, first refine the story before attempting to split it. See the Well Articulated User Stories Quick Start Guide
- 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.
- 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
- 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.
The split patterns discussed here are:
- Workflow Steps Pattern
- Business Rule Variations Pattern
- Simple/Complex Pattern
- Variations in Data Pattern
- Data Entry Pattern
- Operations Pattern
- Defer Performance Pattern
- Break Out a Spike 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:
- As an author, I want to be able to submit my article, so that my content is considered for publication
- As an editor, I would like to be notified when an article has been submitted, so that I can review it in a timely manner.
- As an editor, I need to approve an article, so that the article can be queued for publication.
- As an editor, I would like to be able to request more information, so that I can follow up with the author in a timely fashion.
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:
- Payment currency must be specific to purchase location
- Cash payment denomination amount must not be greater than . . .
- Payment change amount is calculated as . . .
- Receipt bar code is designed using . . .
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 ...
- As a loan applicant, I want to calculate my mortgage payments, so that I can decide which loan type is right for me
Might be made more specific in ways such as ...
- ... calculate my mortgage payments manually
- ... calculate my mortgage payments using an online spreadsheet template
- ... calculate my mortgage payments using an online calculator
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.
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?"
- As a user, I can search for flights between two destinations, so that I can choose the flight that is best for me.
The story above could be modified to qualify what kind of user input might be needed, as follows:
- ...search for flights using simple date input.
- ...search for flights with a fancy calendar UI.
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:
- Internationalization/localization
- Security
- Capacity/Scalability
*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.
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:
- As a shop keeper I want to manage the products being sold in my online store, so that I can sell things people are most likely to want to buy.
If the above story is still too big, it could be further split based on CRUD operations like this:
- As a shop keeper I want to add and remove products from my online store, so that it is easier for potential buyers to find products.
- As a shop keeper I want to edit product details in my online store, so that I can avoid recreating a product to fix a typo.
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.
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:
- As a user, I can pay by credit card, so that my transaction completes rapidly.
You could instead first start with a spike:
- Spike: Choose a technology to use for credit card processing
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.
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:
- 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
- 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.
- 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)
When writing users stories, strive to make sure that each user story satisfies all of the INVEST attributes, where INVEST stands for:
-
Independent
-
Negotiable
-
Valuable
-
Estimable
-
Small
-
Testable
- Independent – To the maximum extent possible, one user story should be independent of another. This is particularly important for stories that are being worked on during the same Sprint, since dependencies between stories make planning, prioritization, and estimation more difficult. Look for ways to split or modify stories to reduce or eliminate dependencies during a Sprint.
- Negotiable - A user story is negotiable, in that the physical story card (or electronic representation of it) is intended to be an “invitation to a conversation” with the team(s) that are going to build it. The details associated with the story are worked out during this conversation.
- Valuable – It is important to word each story so that the business value associated with the story is apparent. This is why the Product Owner plays such an important role in helping the team understand the “why” and the “what” of the user story. The technical detail (the “how”) associated with each story is to be found in the descriptive details and/or individual tasks associated with that story, and the team determines the “how” based on their understanding of the “why” and the “what.”
- Estimable – At the very least, the story needs to be clear enough for the team to be able to do an initial estimate of the story’s relative size. Common issues that can impede the team’s ability to estimate include lack of domain knowledge (which is why the “conversation” around the story is so important) and stories that are excessively large (in which case the story needs to be split into one or more smaller stories).
- Small – At the most basic level, a story has to be small enough to be completed during a Sprint. Depending on team size, sprint length, and other factors, teams typically make stories small enough so that at least half a dozen (and often a much larger number) can be completed during a Sprint. In short, larger stories create problems for teams, and thus teams should seek ways to break stories into smaller parts.
- Testable – If a story is not testable, it is virtually impossible for the team, not to mention the Product Owner, to know when the story is “done.” A classic anti-pattern is when a story contains imprecise language such as “easy to use” (since there is no straightforward way to test ease of use). Therefore, Acceptance Criteria need to be written in such a way that the testing approach can readily be derived from them.
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
It is common for teams to struggle with writing user stories that clearly communicate these things:
- The target user (persona or user type)
- The goal or goals the target user seeks to achieve
- The reason it's important to the user to achieve the particular goal(s)
- The technical approach to be taken to develop the desired functionality, and to test that the functionality works as desired
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:
- Title
- Description
- Priority
- Size
- Acceptance Criteria
- Technical Approach
Just as is the case with other types of titles (aka headlines), a story title should be short, because short statements ...
- Are easier to capture on physical media, like index cards or post-it notes
- Are easier for team members to verbally reference when looking at multiple stories
- Are easier for team members to parse when scanning for stories in a tool such as Jira
Note: The story title maps to the "Summary" field in Jira.
The following format is recommended for story titles: (role) (action) (context)
For example:
- Primary applicant enters passcode
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).
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:
- What data (or other type of input) does a person or system enter or inject?
- What data (or other type of output) results from that input? How will we test it?
Think in terms of vertical slices:
- What is the thinnest possible slice that delivers value?
- What can we do to ensure we are exercising multiple layers? (rather than having separate user stories for different horizontal layers, e.g., UI, database)
Think in terms of the smallest number of words that can convey the story intent:
- "Don't let the perfect be the enemy of the good" (write something down and move on; you can always update it later)
- You may later realize that this user story is either unnecessary or has to be split into smaller pieces (all the more reason not to spend too much time on writing any user story!). Note: The story description maps to the Description field in Jira.
The canonical format for a story description is
- As a (role/persona/user type)
- I want (goal or action)
- So that (desired result from goal/action)
For example:
- As a primary applicant
- I want to enter the passcode I received from my representative
- So that I can access my benefit request and verify the information
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.
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.
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 ...
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.
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.
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:
- Add a text field to the Story issue type (in Project Settings) and call it "Acceptance Criteria."
- Add the Acceptance Criteria to the Description field
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.
Here are several examples of tests written in the Test that ... format:
- AT-1. Test that when a user enters an incorrect old password, they get an error message indicating incorrect credentials
- AT-2. Test that three incorrect submissions of the old password within 1 hour results in the user being logged out from the system
- AT-3. Test that the order confirmation contains:
- Order number
- Estimated arrival date
- Customer service email address
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.
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:
- It is common for multiple stories to reference the same artifact or set of artifacts (for instance, a flow diagram, data flow diagram, or sequence diagram). As long as the team understands where the artifacts are located, and what the contents of the artifacts are, it's not always necessary to attach such artifacts to the story (but it is often helpful to link to their location).
- By way of contrast, wireframes or mockups are artifacts which often are specific to a single story, and as such, it's a common practice to attach or embed such artifacts in the story (linking to such artifacts is often acceptable too).
- Some teams outline the technical approach they are going to follow to implement a story as a series of steps. Each step is often referred to as a "Task," and the process of figuring out what those steps are is called "task decomposition." (in Jira, it is common to use sub-tasks for this purpose).
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.