Success With Agile
- Ernest Heyder
- Jun 8, 2023
- 3 min read
The beginners guide to understanding, and implement, the Scrum Methodology. Agile is a methodology of project management that involves breaking the project into phases and emphasizes continuous collaboration and improvement. In Scrum the teams follow a cycle of planning, executing, and evaluating.
Getting Started
There is a lot of new terminology when learning the Scrum Methodology for the first time. The following terms will provide the context needed for us to continue forward.
Epic: An Epic defines a collection of Features that group together to deliver a single piece of business functionality to the end user.
Feature: A Feature defines a collection of User Stories that group together to deliver a single piece of business functionality.
Story (or User Story): A User Story defines a portion of functionality needed to complete the parent Feature.
Task: A Task is work done by the developer to complete a User Story.
Issue: An Issue is when there is a difference between expected behavior and actual behavior of the application(s).
Bug: A Bug is when User Acceptance Testing (UAT) finds a difference between expected behavior and actual behavior of the application(s).
Backlog: The Backlog is the collection of Epics, Features, Stories, Issues, Bugs, and Tasks associated with a team.
Sprint: A period of time, typically two weeks, for the team to complete the selected Stories.
The first thing that trips up most people when switching from a traditional waterfall approach to Scrum is the "Story Point". A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements. The story point is the replacement for hour estimation used in waterfall. A story point allows for more flexibility in the duration to complete a given item.
Team Working Agreements
The Team Working Agreement defines how the team wants to work together, and what they want in the working environment and from each other to feel safe and free to learn, explore and discover. The working agreement typically includes rules/disciplines/processes the team agrees to follow to make themselves more efficient and self managing. The working agreement must be agreed to by all team members in order to be effective.
This agreement is the first step for any newly formed scrum team. The working agreement can be organized in any way, provided it is clear and unambiguous for all team members. The following are a few key sections to include in the working agreement:
Team Roles
Define the team members that are one the team and the role of each team member. For teams that have have consistent changes in the resources this is provides a way to ensure the document is updated regularly. It is also helpful to define the responsibilities for each role and the main skill sets of each team member.
Definition of Ready (DoR)
The Definition of Ready (DoR) is a checklist of criteria to help facilitate a team's decision to begin working on a new task.
Definition of Done (DoD)
The Definition of Done (DoD) is when all conditions, or acceptance criteria, that a software product must satisfy are met and ready to be accepted by a user, customer, team, or consuming system.
Agile Ceremonies (or Scrum Events)
Each sprint includes several scrum events that help the team plan for the future and iterate on the the current process. The following is a list of the scrum events:
Backlog Refinement
The number of backlog refinements will vary based on the need of the team. Having a standing meeting one to two times a week for thirty (30) minutes is a good starting point for a new team. The team can then increase, or decrease, the frequency to ensure there is always work ready for the next sprint.
It is important the team members spend time refining the backlog outside of the refinement sessions so that the backlog refinement meeting is used to discuss outstanding questions and concerns of the team. The meeting is more valuable when team members are not reviewing the stories for the first time on the meeting.
The goal of backlog refinement is to ensure each story has the details needed for it to be pulled into a sprint. The requirements for the details a story needs to be pulled into a sprint is the teams Definition of Ready (DoR). Only stories that meet the DoR are allowed to be pulled into a sprint.
Daily Scrum (or Daily Standup)
The daily standup occurs on every working day for the team and is ideally only fifteen (15) minutes. During the daily standup helps keep the team accountable to one another and identify blockers that are preventing the team from moving forward.
A good approach to the daily standup is to randomize the order each team member gives there update. This approach will help keep everyone engaged in the conversation.
A typical update from a team member includes the following:
What they accomplished since the last standup.
What they plan to accomplish before the next standup.
Any blockers they are facing.
After each team member gives there update, the floor opens to the team to discuss any blockers or to start working sessions. At this point the daily standup is over and individual team members that are not involved in the "post standup" discussion or working sessions are free to leave the meeting.
Sprint Review (or Sprint Demo)
Feedback is a key part of the Scrum Methodology and is incorporated into every sprint with the sprint review. Typically on the last day of the sprint, the team will demo the work that has been completed to the product owners, stake holders, and other teams. The demo is usually only fifteen (15) to thirty (30) minutes long, depending on the number of questions asked by the participants on the call.
The goal of the sprint review is for the team to get feedback on the items that have been completed. Positive and negative feedback are welcome and encouraged. This feedback supplies the team with the needed information to plan future sprints and adjust.
The sprint review is typically internal to a company and precedes the release of the completed items to a production environment. This means the sprint review is an informal setting and does not require a large amount of preparation by the team. Preparing to much for these meetings impacts the teams ability to deliver and is something to be avoided.
Sprint Retrospective
At the end of the sprint, following the sprint review, the team has a sprint retrospective. The Sprint Retrospective is a reflection, completed by the team, on the last sprint. During a retro the team can provide feedback on what went well and what can be improved upon. It is helpful to use a retrospective board that supports anonymous feedback so that team members have a safe space to voice their concerns.
A sprint retrospective can last anywhere from thirty (30) minutes to three (3) hours. Schedule a followup meeting in the following sprint when the meeting lasts for longer than three hours. Make sure not to cancel any follow up meetings, these meetings are items identified by the team as necessary and need to be treated with equal weight to other work in the sprint.
When conducting a sprint retrospective make sure to keep the goal of iterative improvement in mind. During the sprint retrospective the team will identify the success and failures of the team, and potentially individuals on the team. These call outs are not to single anyone out in a negative way, but to pull the team together to find a solution for how the failures can be prevented in the future. To help keep everyone on the same page start the meeting by reviewing the prime directive, "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."
Sprint Planning
Before a sprint can start the team must be in agreement to the work planned for the sprint. To facilitate the team reaching an agreement team participates in a sprint planning prior to the start of the sprint. The sprint planning typically lasts a maximum of thirty (30) minutes and is the last event of a sprint.
A sprint planning that takes longer than thirty minutes typically indicates additional backlog refinement sessions are needed during the sprint. Occasionally the sprint review will drastically change the plan and cause this meeting to run long. A consistent replanning following sprint reviews indicates the requirements are unclear and the team needs to work closely with the product owner(s) to find a solution to resolve this problem.
The goal of the Sprint Planing is to reach an agreement by team members on the work that is planned for the next sprint. All the planned work that is agreed to by the team is expected to be completed in the sprint. It is a bad practice to plan for more work that can be completed by the team.
Final Notes
A consistent format for items in the backlog makes it easier for the team to review. A template for each is provided bellow as a starting point. Tasks are the exception as they will vary greatly between developers so no template is provided:
Epic
Use an Epic when there are a collection of Features that group together to deliver a single piece of business functionality to the end user. Child links are limited to Features and Issues.
Statement of Purpose:
Defines the who, what, and why for the Epic. The `who` defines the perspective the statement is written and will be the end user of the application(s). The `what` is the collective functionality of the application(s) that will be developed. The `why` is the problem that will be solved by the `what`.
As a <perspective this is written from>,
I want <desired result>,
So that <reason for the request>.
Additional Details: Clarifies the `what` for the Epic. Details listed here might be replicated into linked child Features.
Any information that is considered helpful for understanding the Epic
Risk: Define any risk that may hinder the team from completing all linked child Features. Each defined risk needs to have a mitigation plan defined.
Define identified risks for completing the Epic
Mitigation plan for identified risk
Deliverables: To reduce duplication the linked child Features define the deliverables. For accurate estimations linked child Features must be defined enough for a "swag" effort estimate to be given by the team.
Out of Scope: Define the items that are out of scope for this Epic. Items listed here may be linked as a successor, predecessor, or related item to reduce the complexity of the Epic.
Identified out of scope functionality
Feature
Use a Feature to define a single piece of business functionality for delivery. Typically the business functionality will have an impact on the end user of the application(s), but it may only have an internal impact. Child links are limited to User Stories and Issues.
Statement of Purpose: Defines the who, what, and why for the Feature. The `who` defines the perspective the statement is written and will typically be the end user of the application(s). The `what` is the business functionality of the application(s) that will be developed. The `why` is the problem that will be solved by the `what`.
As a <perspective this is written from>,
I want <desired result>,
So that <reason for the request>.
Additional Details: Clarifies the `what` for the Feature. Details listed here might be replicated into linked child User Stories.
Any information that is considered helpful for understanding the Feature
Risk:
Define any risk that may hinder the team from completing all linked child User Stories. Each defined risk needs to have a mitigation plan defined.
Define identified risks for completing the Feature
Mitigation plan for identified risk
Deliverables:
To reduce duplication the linked child User Story define the deliverables. For accurate estimations linked child User Story must be defined enough for a "swag" effort estimate to be given by the team.
Out of Scope:
Define the items that are out of scope for this Feature. Items listed here may be linked as a successor, predecessor, or related item to reduce the complexity of the Feature.
Identified out of scope functionality
User Story
Use a User Story to define a portion of functionality needed to complete the linked parent Feature. Typically the functionality will have an impact on the end user of the application(s), but it may only have an internal impact. The scope of a User Story is limited to a single sprint, but may be larger on initial creation (before refinement). Child links are limited to Tasks and Bugs. Statement of Purpose:
Defines the who, what, and why for the User Story. The `who` defines the perspective the statement is written and will typically be the end user of the application(s). The `what` is the functionality of the application(s) that will be developed. The `why` is the problem that will be solved by the `what`.
As a <perspective this is written from>, I want <desired result>, So that <reason for the request>. Additional Details:
Clarifies the `what` for the User Story. Details listed here might be replicated into linked child Tasks.
Any information that is considered helpful for understanding the User Story
Risk:
Define any risk that may hinder the team from completing the User Story. Each defined risk needs to have a mitigation plan defined.
Define identified risks for completing the User Story
Mitigation plan for identified risk
Deliverables:
Deliverables are See the Acceptance Criteria section. Tasks will be defined by the resource assigned to the story at on, or before, sprint planning. The Story Points are considered a "swag" estimation until the State is set to Ready. Out of Scope:
Define the items that are out of scope for this User Story. Items listed here may be linked as a successor, predecessor, or related item to reduce the complexity of the User Story.
Identified out of scope functionality
Acceptance Criteria:
Defines the requirements that must be met in order for the User Story to be considered done. See the teams working agreement for more information on what must be present here. Gherkin Syntax is commonly used to help clarify Acceptance Criteria (AC).
<Acceptance Criteria 1>
<Acceptance Criteria 2>
<...>
Issue
An Issue is created when there is a difference between expected behavior and actual behavior of the application(s). An Issue must be linked to a parent Epic or Feature. An Issue is treated like a User Story for planning, pointing, tasking, and time tracking. An Issue can be downgraded to a Bug when; the work is associated to a User Story in the active sprint or the work is completed as part of the work for a User Story in the active sprint. Steps to Reproduce:
<first action>
<second action>
<...>
<last action>
Expected Behavior:
Defines what the application(s) should do when the Steps to Reproduce are completed.
Actual Behavior:
Defines what the application(s) does when the Steps to Reproduce are completed. Additional Details: Optional details provided to help clarifies the Issue.
Any information that is considered helpful for understanding the Issue
Acceptance Criteria:
Defines the requirements that must be met in order for the Issue to be considered done. See the teams working agreement for more information on what must be present here. Gherkin Syntax is commonly used to help clarify Acceptance Criteria (AC).
GIVEN the Steps to Reproduce WHEN executing the Steps to Reproduce THEN the application(s) have the Expected Behavior
Bug
A Bug is created when User Acceptance Testing (UAT) finds a difference between expected behavior and actual behavior of the application(s). A Bug is treated like a Task for planning and time tracking. A bug must be linked to a parent User Story in the current sprint. A Bug can be upgraded to an Issue when; the work is too large to be considered a task or the work is out of scope for the User Story where the Bug was identified.
Steps to Reproduce:
<first action>
<second action>
<...>
<last action>
Expected Behavior:
Defines what the application(s) should do when the Steps to Reproduce are completed.
Actual Behavior:
Defines what the application(s) does when the Steps to Reproduce are completed.
Additional Details:
Optional details provided to help clarifies the Bug.
Any information that is considered helpful for understanding the Bug
Acceptance Criteria:
Defines the requirements that must be met in order for the Bug to be considered done. See the teams working agreement for more information on what must be present here. Gherkin Syntax is commonly used to help clarify Acceptance Criteria (AC).
GIVEN the Steps to Reproduce WHEN executing the Steps to Reproduce THEN the application(s) have the Expected Behavior
Use the following print offs, designed for 4in x 6in print, as a quick reference guide for relating story points to hour ranges. If your team can't print them out, or you want the official print out, contact us.
One optional Scrum Event our team participates in is Team Building. Our Team Building is after work hours, attendance is optional, and friends/family of team members are allowed to participate. Below are a few examples of Team Building activities. Each example is noted for the type of team they support; virtual, in-person, or both.
Board Game Night (In-Person)
Disc Golf (In-Person)
Golf (In-Person)
Wine tasting (In-Person)
Escape Room (In-Person)
Poker with fake money (In-Person)
Online Poker with fake money (Virtual)
Coop Multiplayer Video Games (Virtual)
Jackbox Games (Both)
Comments