What Is Scrum and its Methodology?
Scrum is a framework that helps teams overcome complex adaptive problems to deliver a product with the highest possible value. Many organizations have successfully used Scrum, starting in the early 1990s.
Scrum is founded on empirical process control theory or empiricism. Empiricism asserts that knowledge comes from experience and from making decisions based on what is known.
Scrum employs an iterative, incremental approach to optimize predictability and control risk through continuous learning. This guide explains the complete Scrum Methodology with the best examples.
Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation. There are more than 12 million Scrum practitioners, and the numbers grow daily.
Although it is possible to use some Scrum techniques for projects, Scrum is fundamentally focused on product development.
There are realistic limits to what a single Scrum Team can achieve, however. Organizations may be tempted to simply add more people to the team or more teams to the product to achieve higher velocity, but decades of practical experience have shown this to be counterproductive.
Here are the basic characteristics and features of Scrum:
Iteration length: Ranges between 1 and 4 weeks; a length within this range is initially chosen by the team and then fixed. The most popular is 2 weeks. Values: Commitment, courage, focus, openness, and respect Roles: Product Owner, Scrum Master, Development Team
There are three roles in Scrum: the Product Owner, the Scrum Master, and the Development Team, which are defined as follows:
Team size is essential in a Scrum. Face-to-face communication is preferred by Agile teams; it's open and has a high bandwidth. The larger the team gets, the harder it becomes for each team member to know everything that is going on.
Scrum recommends a team of no fewer than five and no more than nine. Fewer than five (which includes the Product Owner and Scrum Master) and it's believed that the team will be limited in what it will be able to achieve. More than nine and the team's communications will become strained, and information may fall through the cracks.
The Scrum Guide defines three artifacts—Product Backlog, Sprint Backlog, and Increment:
Scrum uses an incremental approach to delivering. It achieves this by working in iterations known as Sprints. The recommended length for a Sprint is between a minimum of 1 week to a maximum of 4 weeks. Most teams opt for a 2-week Sprint:
The Sprint isn't the only aspect of Scrum that has a time limit, also known as time-box. All of the events, such as Sprint Planning, the Daily Scrum, and so on, are also time-boxed.
The aim of time-boxing an event is to ensure focus is maintained. The time-box for each event is proportional to the length of the Sprint and is set out in the Scrum guidelines.
The Sprint starts with Sprint Planning, a meeting where the whole team comes together. The aim of the first part of Sprint Planning is for the Development Team to forecast which items, from the top of the already prioritized Product Backlog, they think they can achieve in the coming Sprint.
Several factors influence their decision including the following:
1. The latest product increment.
2. The items in the Product Backlog.
3. The team capacity for the upcoming Sprint; for example, are any members on leave?
4. How did the team perform in the last Sprint?
5. Are there any work items being carried over from the last Sprint?
The usual process will involve the Development Team taking the next story from the top of the Product Backlog and discussing whether they think they can complete it as part of the coming Sprint. Usually, this begins with one of the team reading the story aloud, including the acceptance criteria.
The Product Owner should be available for questions if the Development Team needs any clarifications. If, after discussion, our team believe they can complete it in the coming Sprint, they put it on the Sprint Backlog. They then take the next story from the Product Backlog and repeat the process.
Once the Development Team has determined the items from the Product Backlog they think they can achieve, the Scrum team as a whole work to set the Sprint Goal.
Sprint Planning - part 2
The second part of Sprint Planning is for the Development Team to determine how they will do the work. Deciding how involves discussion and breaking down the work into tasks, for each Product Backlog item in the Sprint.
At the end of the Sprint Planning Meeting, the resulting set of work items, including the Sprint Goal is collectively known as the Sprint Backlog.
Once ready, the Sprint Backlog is added to the team's Scrum Board. For Scrum teams, this usually takes the form of physical board, such as a whiteboard or similar, and would look something like as follows:
The Daily Scrum
Once the Sprint is in progress, the Scrum team meets each day to coordinate their work. This meeting is called the Daily Scrum.
The Scrum team will congregate around the Scrum Board and discuss what they've achieved since they last met, what they will be working on until they next meet, and whether there are any problems, or if there is anything in their way.
The Development Team will update the board as necessary, moving tasks from left to right as applicable. This Scrum Board’s primary function is to help the team to coordinate their work, ascertain progress, and quickly uncover any assumptions or identify any risks in their plan. The team should remain focused on meeting the Sprint Goal; as such, this is a key inspect-and-adapt meeting for the team.
The meeting is timeboxed to 15 minutes to keep it purposeful and focused. Although the Scrum Guide doesn't indicate this should be a standing meeting, many Scrum teams will stand for their Daily Scrum.
This is something that's been adopted from the Extreme Programming community. The aim of making it a standing meeting is to keep it short; people are less inclined to talk at length if they're standing.
The Sprint Review
The Sprint Review is the first meeting held at the end of the Sprint cycle. The attendees include the Scrum team and stakeholders for the product. The working software for each completed User Story is demonstrated to the group.
The Sprint Review aims to inspect and adapt the business value delivered by this latest increment, to see if we can optimize it further. Based on the feedback gained, the Product Owner can then adjust the backlog (adapt the plan) accordingly.
A scrum of Scrums Description
Scrum of Scrums is a technique that enables the effective synchronization among interrelated teams. Each team designates a representative, often the scrum master, to participate in the scrum of scrums events, and to ensure that the teams are coordinated and synchronized.
The scrum of scrums encourages a daily meeting where the representatives communicate and collaborate about issues, risks, and status across teams.
Scrum of Scrums Master
Team Representative (often the scrum master from each team)
1. Each scrum team identifies a representative to share information at the scrum of scrums events.
2. The scrum of scrums meeting should occur daily at the same time.
3. Each representative should share what was completed by their team, next steps, and impediments from the team they are representing.
4. Discussions will focus on coordination between teams and clarify responsibilities and boundaries.
5. An independent backlog will be maintained for the scrum of scrums team.
Scrum Wall/Scrum Board
A scrum wall/scrum board is a visual information radiator for displaying the current state of user stories and tasks within a team. Transparency is an important principle in the scrum, and the scrum board is a way for a project to display what is being worked on, what is in progress, and what has been completed.
If the team is at one location, then a physical scrum board is recommended, but distributed teams may wish to implement tools within popular agile application life-cycle management systems. The scrum board is continuously updated throughout each sprint.
1. Identify a location for the scrum board. Ideally, this is in a place that the team will be able to view it throughout the day.
2. Prepare a wall surface and gather needed supplies such as markers, sticky notes, and tape. Alternatively, magnetic cards can be used with aluminum whiteboards.
3. Identify the columns for the items that will be tracked. The columns that are generally used are:
a. Sprint backlog.
b. To do: Place for all cards that are not in the “Done” or “In Process” columns for the current sprint.
c. Work in process (WIP): Any card currently being worked on goes in the WIP or “doing” column. Each team member self- subscribes to a story, and moves it to the WIP column when ready to start work on the story.
d. Verify: Many tasks have corresponding test tasks stories. These are placed in the “verify” column.
e. Done: Completed cards are moved to the “done” column and are removed at the end of the sprint.
4. Create a card for each user story in the current sprint.
5. Create a card for each task in the current sprint.
6. At any time, team members can update task information.
7. During the daily stand-up, the board should be updated by moving cards to the appropriate columns if required.
Self-Selection/Self-Subscription is a core agile value that encourages team members to own their decisions by selecting the work that they will do based on skills, interest, and the team’s needs.
It works best when used during a facilitated ceremony where a scrum master or another facilitator ensures that product owners, project managers, other managers, or other outside influences are not tasking individual team members. The highest level of team member commitment is achieved via self-selection, a technique that enables self-organization.
1. Encourage self-selection as a core value in the organization.
2. Incorporate self-selection in all planning ceremonies where work is connected to the team members who will complete it.
3. Scrum masters should ensure that all stakeholders respect self-selection and to coach those who do not.
Spike (Design Spike) Description
A Spike is a solution-specific experiment, often taking place during an entire sprint, but sometimes in shorter durations, aimed at answering a question or gathering information important to the team’s success.
Spikes are sometimes referred to as “design spikes,” or “sprint prototypes,” and are described as the simplest output (typically code, but often a design or other work product) that can be built to confirm the team is on the right track.
Teams will often routinely include stories for experimentation with spikes during sprints early in the produce development life cycle.
1. Develop a user story for spikes as if they were any other backlog item.
2. Estimate using story points, or hours if they are at the task level.
3. Develop tasks, if required.
4. Demonstrate outcomes internally to team members.
5. Gather data for input into backlog grooming.
A sprint is a timeboxed event where most work gets done, and typically has a duration of two to four weeks. Several ceremonies are embedded in a typical sprint, including sprint planning, sprint demos/reviews, retrospectives, daily stand-ups, and backlog grooming.
A sprint should begin with sprint planning and end with a retrospective. Some agile teams allocate days prior and after each sprint to conduct planning and retrospectives, but the outcome is more predictable to include it within the sprint.
During a project, sprints should have a consistent duration. When one sprint ends, another immediately begins. Each sprint should have a defined goal, and no changes in scope should be made during a sprint.
At the end of each sprint, a set of user stories should be completed and ready to deliver to the customer, although it is common to put completed code “on the shelf” waiting for other interdependent stories to be completed.
Sprints may be used for other purposes, including:
An envisioning sprint is for developing a long-term product vision.
A sprint zero sets up the basic infrastructure for a project.
A design sprint is for developing a high-level design.
An improvement sprint is for developing and deploying performance improvements.
Agile Team and Agile Leader
Process Improvement Team Members (for improvement sprints)
1. Establish key roles such as product owner, scrum master, and team members.
2. Determine sprint duration.
3. Identify the ceremonies that the agile team will use during each sprint. Define the day, time, and duration for each ceremony.
4. Conduct sprint planning to create the sprint backlog, and have each agile team member select the user stories for which they will be accountable.
5. Conduct daily stand-ups to understand progress, impediments, and risks.
6. Conduct backlog grooming to maintain the backlogs and develop a view for the next sprint.
7. Complete user stories in the sprint backlog.
8. Conduct a sprint demo/review to demonstrate what was completed during the sprint.
9. Conduct a sprint retrospective to learn what went well, what did not go well, and action items for improvement during the next sprint.
10. Repeat sprints until the product backlog has been depleted, funding runs out, or until the project ends.
Sprint Demo Description
A Sprint Demo (also called Sprint Review or Show and Tell) is a collaborative technique used to ensure that key stakeholders are aware of, and accept, the value being delivered at the end of each sprint.
During the sprint demo, the work that was completed, as well as the forecasted work that was not completed, is demonstrated to the product owner and other customers.
The sprint demo occurs at the end of each sprint, immediately prior to the retrospective; and is a form of acceptance, communication, validation, and recognition that the team has reached its intended goal.
1. The work completed for each user story delivered in the sprint is compared against the criteria described in the definition of done.
2. The project stakeholders participate to ensure that expectations were met, and any issues are addressed. An explanation may resolve an issue, or an adjustment might need to be made to the product backlog.
3. Proper planning of the sprint demo is required in order to ensure that the correct stakeholders are present, the right technology is installed, and that the agenda is set and agreed to. The goals of the sprint demo should be distributed in advance.
4. The sprint demo should be integrated into the milestones of the top-level plan.
5. Any issues with the attendance of key stakeholders should be identified and addressed immediately to minimize disruptions.
6. The team should address any questions about the work accomplished during the sprint during the meeting. Issues that cannot be resolved should result in new backlog stories or updates to existing stories.
Sprint Planning Description
A sprint planning meeting occurs at the beginning of each sprint and is a negotiation between the agile team and the product owner as to what value can be delivered in the upcoming sprint. During the sprint planning meeting, a sprint backlog is developed and tasks are identified to support the forecasted user stories.
Team members assess how much work they can accomplish during the sprint based on known velocity, and the team members subscribe to the various stories and tasks to be completed.
A sprint planning meeting should take place at the beginning of each sprint and should identify the value to be delivered during that sprint. The product backlog, which has already been sized and prioritized, is the primary source of stories for the sprint planning meeting.
The goal of sprint planning is to agree on a sprint backlog that aligns with the team’s historical velocity and contains tasks, usually estimated in hours, and owners for each story.
A sprint plan that is understood, realistic, and created by the team members who are the same people doing the work is a critical influencer of project success.
Product Owner (for context)
1. Ensure that the scope of the sprint is clear and that all work items are included. Teams can easily overlook non-software work products in their planning, including testing and documentation, as these oversights have the potential to negatively affect velocity.
2. Ensure that estimates are provided for all work to be completed during the sprint.
3. Use planning poker, or another relative sizing method, to estimate stories taking care to not to exceed the known velocity.
4. Allow each team member to review the plans and estimates for the sprint prior to committing to the forecast.
5. Set the expectation that adjustments will be made to the sprint plan based on vacations, training, or other external influences that could impact the velocity.
6. Set the expectation that adjustments will be made to the sprint plan based on the team’s capability, issues, and risks.
7. Ensure that each team member commits to the plan prior to beginning the sprint.
Stakeholder Identification and Management Description
Stakeholder identification and management is the process used to identify all stakeholders for a project, and how they will be involved. It is important to understand that not all stakeholders will have the same influence or effect on a project, nor will they be affected in the same manner.
Once stakeholders are identified, a definition of how they interact should be defined by identifying which stakeholders are required at each ceremony, event or milestone. It is helpful to identify expected roles, responsibilities, and frequency of engagement.
An outcome of identifying stakeholders should be a project stakeholder list, matrix, set of sticky notes on a board, or a RASIC (Responsible, Approves, Supports, Informed, Consulted) chart, where attributes such as the level of influence, frequency, and accountabilities are captured.
1. Ensure that stakeholder identification considers the project, team, functional groups, and organizational participants.
2. Capture the names, contact information, titles, organizations, and other pertinent information of all stakeholders.
3. After the analysis is complete, the level of stakeholder engagement should be estimated and should identify when the stakeholders will participate in project activities.
4. Stakeholder engagement is monitored during the project, and a team engagement score (TeamScore) should be created and trended.
State of the Team Description
A State of the Team is a gathering of multiple teams to understand what has been accomplished by each team, and what is needed from other teams, functional groups, or leadership. The state of the team allows all stakeholders to understand a global view of all status and progress.
This allows leadership to assess the organizational risk profile, and determine where support is needed, as well as an opportunity for teams to learn what others are experiencing. It is an important tool to build trust and understand progress at an organizational level.
1. Create a schedule of State of the Team meetings.
2. Develop a simple agenda that is common for all team. Teams should not have to prepare but should be able to summarize the information they are already collecting from daily stand-ups, retrospectives, and sprint demos.
3. Go beyond status and capture the best ways to solve each team’s problems with the collective experience in the room.
4. Stay agile. The meeting time will depend on the number of teams; however, a good rule of thumb is 15 minutes per team.
SWOT Analysis (Strengths, Weaknesses, Opportunities, Threats) Description
A SWOT analysis is a strategic planning tool that helps a business entity identify their strengths and weaknesses, as well as opportunities and threats that may exist in a specific business situation.
A SWOT analysis is most commonly used as part of a sales or marketing plan, but it is also a good tool for agile teams to use as a starting point for projects or sprints.
A SWOT analysis is usually depicted as a square divided into four quadrants.
Each quadrant represents one element of the SWOT analysis (Strengths, Weaknesses, Opportunities, and Threats).
1. A series of questions are used to begin filling in each quadrant. Start with strengths:
a. What do we do well?
b. What are our unique skills?
c. What expert or specialized knowledge do we have?
d. What experience do we have?
e. What do we do better than our competitors?
f. Where are we most profitable in our business?
2. Weaknesses may include attributes that will impede progress in achieving objectives. Ask questions, such as:
a. In what areas do we need to improve?
b. What resources do we lack?
c. What parts of our business are not as profitable?
d. Where do we need further education and/or experience?
e. What costs us time and/or money?
3. Opportunities are external conditions that will help you achieve your objective. Ask questions, such as:
a. What are the business goals we are currently working toward?
b. How can we do more with existing customers or clients?
c. How can we use technology to enhance our business?
d. Are there new target audiences that we have the potential to reach?
e. Are there related products and services that provide an opportunity for new business?
4. Threats are external conditions that could damage your business’s performance. Ask questions, such as:
a. What obstacles do we face?
b. What are the strengths of our biggest competitors?
c. What are our competitors doing that we are not?
d. What is going on in the economy?
e. What is going on in the industry?
5. Follow up on the SWOT analysis:
a. Create a plan to build strengths.
b. List ways to work on mitigating weaknesses.
c. Create a plan to use strengths to eliminate the threats.
d. Combine strengths and opportunities to develop new strategies.
e. Review weaknesses and opportunities to create improvement ideas.
Team Agreement Description
A teaming agreement is a social contract entered into by members of an agile team to define team behaviors, expectations, and standards.
Some team agreements are simple ideas written on a whiteboard, while others are detailed charters that contain important facts about the team itself. Team agreements are typically developed at the beginning of a release and can be updated after each sprint retrospective or sprint demo.
Self-organization is an important goal for any agile team, and a self-organized team clearly defines the parameters for team operations. Individual agile team members may have specialized skills and areas of focus, but accountability belongs to the team as a whole.
A simple yet compelling team vision is an excellent way to get upper-level management behind a project.
1. Create a shared vision that helps the team to have an identity and a common purpose. A shared vision should be visible, compelling, and understandable by any stakeholder who sees it.
2. Make sure the resources needed by the team to achieve the shared vision are available.
3. Select a name for your team and record it in the team agreement.
4. Set the expectation that the shared vision is a living document that should be updated and improved as the team learns through the product development process.
Team Estimation Game Description
The Team Estimating Game (sometimes called the Fibonacci Team Estimating Game) is an agile estimation technique that establishes relative sizing using story points and a rough order of magnitude estimation. Planning Poker is a similar technique that uses playing cards to depict story points.
This agile technique tries to solve the estimation problem by using an estimating game to size backlog items relative to one another.
The relative size of a backlog item is intentionally disconnected from the effort in hours to encourage the team to think in a different way. “Roughly right” versus “accurately wrong” is the ultimate goal of the team estimation game.
The scrum team, working with a scrum master and product owner, sizes each epic or user story as part of product backlog grooming or sprint planning. The product owner’s role is typically informational only, as they are not involved in the building of the actual product.
1. Use cards or sticky notes with user stories that are placed on a board.
2. The game consists of three rounds of collaborative sizing negotiation by the agile team.
3. To begin the game, a single story is pulled off the backlog and placed in the middle of the board.
4. During each round, stories are taken off the backlog and placed on the board in a location that is either larger (to the right) or smaller (to the left) than the stories that are already on the board.
Each team member is allowed to change the location of one of story, as long as they can logically explain the reason for the change. They may choose to either place a new story, or move an existing story, but not both.
5. After each round, the team discusses the sequence of stories on the board, with each team member offering advice based on their area of expertise.
6. Once relative sizing is determined, numbers in the Fibonacci sequence are drawn on the board, and stories are moved to the left or right under the appropriate number based on the team’s understanding of the complexity and risk of the story. The basic order of the stories cannot be changed.
7. Always use the Fibonacci sequence, as this is the recommended unit of measure for relative story-point sizing.
Team Room Set-Up Description
An agile team should have their own space, known as a Team Room. Team room set-up is typically done when a new team is formed, or a new project is set to begin. Elements of a team room that need to be considered are listed below.
Size of the room
A workstation that supports pair programming
White Boards/Flip Charts
1. Secure the dedicated space for each agile team.
2. Identify the room layout and all key elements that will be needed.
3. Purchase or secure all elements for the team room.
4. Assemble the team room and reevaluate assembly during retrospectives.
Technical Debt Description
Technical Debt is incurred when the agile team proactively determines that a less optimum, less efficient, or less robust solution is appropriate given constraints of time, budget, or resources.
As this graphic from Martin Fowler describes, as technical debt increases, the costs and effort to continue development, or maintain an existing system, will become too high, and a “technical debt sprint” should be scheduled within a release to improve code quality.
The challenge for any Development Team is that:
The business community likes technical debt due to short-term gains.
The technical community dislikes technical debt due to long-term pain.
1. Quantify the technical debt and balance the business needs with the technical needs of your projects.
2. Leverage the practices in sprint planning to plan, prioritize, and sequence the elimination of technical debt by allocating them as user stories to future sprints and releases.
3. The decision to incur technical debt should be proactive and not the result of defects or coding errors.
Test-Driven Development Description
Test-driven development (TDD) is an agile technique where a developer will write a basic test case to verify the desired functionality, knowing that it will fail, and then writes the minimum amount of code to pass the test.
The developer will then enhance the code to ensure that it meets acceptable performance and coding standards and principles.
Test-driven development brings the most value when used with short sprints, where rapid experimentation is possible.
1. Incrementally create test cases and related software that fails initially, but eventually passes each test case. An automated test framework is normally used to encourage efficiency.
2. If manual testing is used, save test cases for the future to ensure that changes to the software do not cause unintended defects.
3. Use the test case inventory to evaluate requirements changes.
Three Diverse Humans Description
Three Diverse Humans, or TDH, is a User Story and Design validation technique that involves review and input for three separate, but equal, individuals prior to Product Backlog generation, or commitment to a complex design.
The typical TDH session is a one-hour, rapid-fire meeting that includes a developer, an analyst/SME, and a tester, but it can be attended by alternative roles as well.
Others as Alternates
1. The TDH session begins with an agreement of the backlog stories or design to be reviewed.
2. Five minutes of discussion, led by the author of the work product.
3. Feedback by non-author participants from their perspective. For example, a tester might provide feedback of additional tools, environments, or technology that is required, while a developer may offer suggestions for downsizing a story.
4. The User Story or Design is adjusted in real time, if possible, or placed on the backlog for a design sprint, spike, or backlog grooming session.
Agile teams are learning teams. There are different ways to train team members, but each one should be designed with outcomes that build capability. Organizations should identify what training methods will work best for each scenario, and ensure that all team members have the capabilities to meet their commitments.
Professional Training is typically related to certification or a profession.
Technical Training is related to the technological aspects of the job.
Soft Skills are communication and personal skills that help to ensure success in the work environment.
Team Training addresses the process the team agrees to adopt.
1. Determine organizational and team training needs. This may be captured in a training backlog.
2. Ensure that consideration is given to training goals, budget, and resources.
3. Develop a plan of execution that includes what training method will be used and a timeline.
4. Ensure that accountability is assigned for accomplishing planned training and monitoring to completion.
Unit Testing Description
Unit testing is a technique applied by individual software developers to ensure that the smallest, self-contained pieces of code function as designed and provide the correct results.
Because manual unit testing is time and effort intensive, many tools exist to automatically run unit tests based on design elements coded directly within code modules. Continuous Build/Integration tools ensure that code is unit tested with no failures prior to check-in of code.
Organization (e.g., Infrastructure or Support)
1. Provide the infrastructure and support at the organizational level to implement automated unit testing for each team.
2. Create team agreement items related to unit testing all code.
3. Ensure that the developers are trained in how to design code to support automated unit testing.
4. Ensure that automated testing provides demonstrable value, and improves scripts if it does not.
Velocity is a historical definition of a given team’s ability to deliver value during a consistent sprint duration.
Velocity is used by agile teams for sprint and capacity planning, and to predict whether teams will successfully meet their sprint forecast.
Velocity is team and duration specific, meaning that as a team changes, they cannot expect its velocity (value delivered) to remain constant. Any change to the team or sprint duration will affect the team’s ability to deliver.
During sprint planning, an agile team will set a velocity objective for the sprint based on historical data. A burn down (or burn up) is used to depict a team’s actual velocity during a sprint or release.
1. Depend on velocity for sprint planning if the team and duration remain constant.
2. Do not attempt to normalize velocity or story-point values across multiple teams.
3. Do not attempt to assign hours or days to story points. The usefulness of velocity is based on its unit of measure being value, not time.
Visual Information Management Description
Visual information management is the practice of using information visualization techniques to depict important information to a large group of people. Visual information management is a clear, simple, and effective way to organize and present the result of a team’s work.
It can also be perceived as fun by the teams since visual elements bring color and life into an otherwise sterile office environment. Visual management will positively influence the behavior and attitude of team members, managers, and stakeholders by helping build transparency and trust.
The term “information radiator” is used to describe any artifact that conveys project information and is publicly displayed in the workspace. Information radiators are an essential component of visual information management, and they can be any handwritten, drawn, printed or an electronic display that the team places in a highly visible location.
1. Use highly visible information radiators to convey cultural norms:
a. The organization is committed to transparency.
b. The organization is committed to high trust.
2. Use information radiators elicit conversation when visitors are with the team.
3. Take advantage of whiteboards, flip charts, poster boards, or large electronic displays as information radiators.
4. Regularly update information radiators to keep the teams interested and informed.
Acceptance Testing Description
Acceptance testing, also known as User Acceptance Testing (UAT), provides the customer with an opportunity to validate that the product increment or released system is able to handle real-life scenarios and transactions.
Some of this can be addressed in Sprint Demos/Reviews, but often systems become so complicated that more formal acceptance testing is required.
To get the most valuable feedback, testing should be performed by an actual end user, or qualified designate, and should be conducted on the production system in the actual or simulated production environment.
The goals of UAT include gaining the customer’s approval of the system or product and clearly identifying any defects or issues and capturing changes to existing use cases or user stories.
1. Conduct UAT at least once in the product development cycle. UAT can be performed during Sprint Reviews and/or at the conclusion of planned releases.
2. Engage one or more end users to perform the testing.
a. If an end user is not available, have another customer do the testing.
b. If the customer is not available, have the product owner do the testing.
Note: The risk of not having an end user or customer participate in testing is that the user community may identify defects after product delivery.
3. Agree upon the test procedures and acceptance criteria before UAT begins.
4. Understand usability problems and any desired changes by having the development team observe the testing activities.
5. Document defects and desired changes. Relate defects and changes to user stories or use cases.
The Sprint Retrospective
The Sprint Retrospective usually follows on immediately from the Sprint Review and is the last meeting of the iteration. It's an opportunity for the Scrum team to inspect and adapt its process.
In general, the Scrum team will ask itself what went well during the Sprint, what didn't go well, and what it can improve. They should consider aspects such as team dynamics as well as processes and tools. The outcome of this meeting is for the team to come up with actionable improvements that it can carry out during the next Sprint.
Most Scrum teams add additional events to their Scrum workflow. A good example is called backlog refinement, an event which some teams hold as regularly as once per week, or at least once per Sprint.
The backlog refinement meeting aims to look at the top stories on the backlog and prepare them to be worked on in an upcoming Sprint. Part of this preparation will include estimating the User Stories, which will tell us whether:
1. We have enough information to able to start working on the User Story
2. We've broken the story down into a small enough chunk; a User Story must be small enough to be completed in one Sprint
Estimates are usually given in Story Points; we'll talk more about those in the following two blogs.
XP - Extreme Programming
Extreme Programming (XP) is the second most popular framework, used by roughly 10% of Agile teams. XP stands out as one of the few Agile frameworks that prescribe technical practices.
For instance, peer review is considered so important; when dialed up to 10 we do peer review all of the time. If all code is written while working with another programmer, we are code reviewing continuously. So XP makes the rule that all software that is destined for a production environment must be Pair Programmed.
He applied the same thinking to unit testing. XP deems unit testing so valuable it makes it a rule to write the unit test first before any code is written.
Writing tests first, also known as Test-Driven Development (TDD), is a practice that supports the creation of simpler code designs because just enough code is written to fulfill the test specifications.
The resulting automated test suite also inspires the confidence to make subsequent changes to the specification tests and code, in the knowledge that if the tests still pass, other parts of the system are unaffected by the change.
So this is how XP got its name. It prescribes core programming practices and turns the volume on each up to maximum, taking them to the extreme.
Introduction to the mechanics of XP
Here are the basic characteristics and features of Extreme Programming:
Iteration length: Ranges from 1 to 3 weeks, with a preference for the shortest possible
Values: Communication, simplicity, feedback, courage, and respect
Roles: Customer, Development Team
Team size: small, 2-10
Artifacts: Release plan, iteration plan, User Stories, tasks, CRC cards Technical practices: Pair Programming all production code, TDD, metaphor, refactoring, collective code ownership, Continuous Integration, daily builds, Spikes, sustainable pace
Events: Release planning/iteration planning, daily standup
Special features: Prescribes technical practices, gathers requirements with User Stories, promotes working at a sustainable pace
Lacks: Compromise—it's a fully committed, all-or-nothing approach
These are the roles XP recommends for a team:
There doesn't need to be a one-to-one relationship between team members and functions. One person can perform more than one role.
For example, the person who has the Coach role could also have the Tracker role. Some instances of combined roles are Programmer-Tracker, Programmer-Tester, and Coach-Tracker. Some roles shouldn't be mixed; for example, for the Coach to remain objective, they probably shouldn’t combine with anything except Tracker.
The same is true for the Customer, where we will also want to avoid conflicts of interest. Plus it's a time-consuming role in its own right.
XP requires that the Customer is part of the team; their involvement throughout the product development life cycle is key to its success.
In XP, it's assumed that the customer has the most information about the value of what is being built. At the same time, it's expected that the Development Team has the best idea of how to implement that value and how much it will cost.
While this may be a radical shift from your current way of working, you'll be amazed by the results of having the customer on the team —I've seen this work well many times.
We may be the experts at building software, but our customer is the expert in their domain and is the person closest to the real-world problem that we're trying to solve.
XP uses iterations to deliver working software incrementally. The iteration length is anywhere from 1 to 3 weeks. The team should pick an iteration length and fix it, only changing it if it's necessary:
The planning game
We start the beginning of each XP iteration with the planning game, an event in which the whole team participates. It is split into two phases, Release Planning, and Iteration Planning, which we'll take a look at now.
Part 1 – Release planning
A new phase of work begins with release planning, a whole team meeting which is used to create a release plan. It commences with the customer/business introducing new problems for the team to solve.
At this early ideation phase, the customer will often be thinking in the form of software features. These are written on index cards in the format of users stories.
XP emphasizes that business people are to make business decisions and technical people are to make technical decisions. The Development Team, therefore, leaves the customer to write the User Stories.
The following is an example User Story from a cinema ticketing system:
On the top half of the index card, the narrative of the User Story is written. It typically follows the format given here:
As a <certain type of user> I want to <perform some action> so that I get <some outcome>.
In the example User Story given here, the precise type of user is the cinema goer. The action they want to perform is to purchase tickets and reserve seats for a particular session. Finally, the outcome the Cinema goer would like is to watch the movie.
On the bottom half of the index card, the acceptance criteria are written. These help the team to understand what expected behavior is to be delivered as part of this User Story. These are the criteria that the customer will use to determine if the resulting software works as they were expecting.
User Stories are business problems formulated to fit on an index card. They are deliberately kept in this small format to enable the 3 Cs to happen: Card, Conversation, and Confirmation.
In this way, active discussion occurs between the customer and the Development Team during implementation. Leading to fewer assumptions being made when compared to traditional requirements gathering.
For each User Story, the Development Team will gather enough information from the customer so that they can estimate it. At the release planning level, estimate in ideal weeks. An ideal week is a week where we can focus entirely on implementing the User Story without any distractions.
Estimates should fall between one and three ideal weeks. If the User Story is bigger than three weeks, it should be broken down. If it is smaller than one week, then it may need to be combined with others.
It's not unusual in a release planning meeting to see the User Stories spread around the table. Viewing all the stories like this helps the team absorb the bigger picture and will ultimately make it easier for the customer to identify any gaps.
With index cards, it's easier for both the customer and the Development Team to move the cards around and start to formulate a plan. Priority is given to stories with the highest business value.
The outcome of release planning is the release plan, a deck of User Stories written on index cards, estimated by the Development Team and prioritized by the business.
Work on the release plan begins with the preparation for the next iteration; this starts with the iteration planning meeting.
Part 2 – Iteration planning
Phase 2 of the planning game focuses on planning the next iteration. The release plan is the principal ingredient to this process. If this is the first iteration, that's all we need. If, however, this isn't the first iteration, we'll also need the following:
1. The team's project velocity. Velocity tells the team how much stuff we can get done in one iteration. To calculate it we take the estimates for the work completed in the last iteration and total them.
This total is then used by the team to help them determine the right amount of work to commit to for this iteration. User stories are estimated in ideal weeks, so if we completed User Stories with a total of five ideal weeks, our velocity would be 5.
If the team doesn't have a project velocity, that is, it's their first iteration, they will have to use a degree of gut feeling. It will take at least 3 -4 iterations before their velocity begins to stabilize.
2. As with Scrum, any User Stories that are still in flight from the previous iteration are carried over.
This includes any unfulfilled acceptance tests or bugs. Work that is carried over usually takes precedence as it was previously prioritized higher than the other items on the Release Plan. These user stories are placed at the top of the Release Plan for this round of iteration planning.
With all these factors available to it, the team goes about planning the next iteration. It does this by selecting the next story from the top of the release plan and starts to break it down into smaller, more manageable chunks, known as tasks.
Tasks are estimated in terms of ideal days, which is how many days it would take to complete the task if there were no distractions. Half days can be used if necessary. The breakdown of tasks should be done by the people carrying out the work.
The team keeps selecting User Stories from the top of the release plan deck and breaking them down into tasks until they hit their project velocity, or they decide they can fit no more into this iteration.
Some teams assign tasks to developers during iteration planning, some teams don't. It does depend on how you break down User Stories into tasks and whether your team operates as specialists or generalists.
It's more fluid if we don't assign tasks and we just let the next available pair pick up the next item to be done.
Implementing the iteration plan
Once the planning is complete, the iteration begins. If a programmer doesn't already have a task, they take the next available one and find a partner.
If necessary, design work will be carried out at this stage, including the use of Class Responsibility Collaborator (CRC) modeling of Object-Oriented Design (OOD), and other design tools such as UML Sequence Diagrams.
The pair will begin coding in a TDD way by writing a failing test. They then write the code that fulfills the test. Once the test is running, they then look to refactor the code, as the following diagram illustrates:
This cycle continues until the task is complete.
Each day the team will meet in the form of a Daily Standup; this is a 15-minute meeting where, as the name suggests, everyone stands. The aim is to coordinate the team's work.
Each team member or pair will talk about what they've implemented since yesterday's standup, what they'll look to achieve before the next standup, and what, if anything, is in their way.
XPers aim to integrate early and often; they favor a practice called Continuous Integration (CI). They will typically commit work every few hours, providing, of course, all of their unit tests pass. Modern CI practices offer an automated way for the latest changes to be incorporated.
Teams will often set up their CI server so that it automatically checks out the newest version, builds it, and runs the tests. Their practices and workflow shouldn't allow them to commit code and proceed unless all tests pass.
Once the story is complete, the software is made available for acceptance testing. The customer executes the scenarios they've created around the acceptance criteria of the User Story, so they can determine whether the software is complete.
Many teams now automate their acceptance testing as part of their TDD approach, a technique known as Acceptance Test Driven Development (ATDD).
As with Scrum, the demo is an opportunity to invite stakeholders along so that they can see progress and give feedback.
The focus is on a demonstration and inspection of the working software completed during the iteration. Information gathered from the demo can be fed into the release planning ahead of the next iteration, and if necessary changes can be made and the release can be re-planned.
Similar to the idea of the Scrum Retrospective, the iteration retrospective is an opportunity for the team to take stock of how things have gone during the past iteration and determine whether it can make changes to its process for the better.
Kanban and Lean Software Development
In this section, we look at Lean Software Development and its origins in Lean Manufacturing. We'll first discuss the thinking that led to significant breakthroughs in responsiveness and quality on the Toyota production line. We'll then look at how we can apply those to software development.
The following timeline shows a brief history of Lean and Kanban:
Lean Software Development and Kanban have their history in manufacturing and the work done by one company, in particular, Toyota Motor Corporation.
In its effort to economically mass-produce affordable motor vehicles for people after the Second World War, Toyota made profound changes to the way it organized its production line.
Toyota realized early on that there was a significant waste in manufacturing, which added to the overall cost. They implemented two notable changes to typical mass production lines, which had a profound effect on reducing costs and significantly increasing quality.
1. Reduce all waste which didn't add value to the customer
2. Focus on single-piece flow through the production line using a pull system
Waste was identified at multiple levels, for example, overproduction of a particular part was seen as a waste for two reasons. Firstly, space was needed to stockpile the part until it could be used. This cost money not only for storing it but also took up floor space that could be used for production.
Secondly, sometimes problems in the manufactured parts weren't found until they were combined with other parts and put to use further down the production line. If a problem were discovered that required the entire batch to be re-machined or re-manufactured, this would add significant time and money.
In a production line environment, there are multiple workstations each of which takes the work of preceding stations and combines it or enhances it before passing it on to the next workstation. In this way, each station adds value and passes it further down the production line until the product being built is complete.
In a traditional product line environment, the work was pushed from one station to the next. Sometimes the work was sent in batches.
For example, the machine that built widget A, with some amount of retooling, also built widget B. Rather than lose time due to retooling, if you built batches of say 100 at a time, the machine operation was more efficient.
This can create unevenness in the production line, which can lead to fluctuations in the flow; sometimes a station further down the line could be waiting for the previous station to complete a batch of Widget As and retool because it needs two Widget Bs.
To solve these problems, Toyota perfected a system called Kanban. A Japanese word meaning signboard, Kanban is used in lean manufacturing to signal when a piece of work needs to be done.
The profound change that Toyota's employee Taiichi Ohno implemented in this signaling system was to reverse the flow of information on the production line.
This means that stations further down the production line would send Kanban signals to the stations behind them that they needed certain parts made.
The following figure shows how a Lean Production Line works:
A Lean Production Line waits until there are orders for its product because the communication channel is reversed. The order being placed is a signal to the end of the production line that it needs to deliver more finished products.
It does this by sending requests to the stations preceding it in the production line so that they can make and assemble the necessary parts for it to deliver a finished product.
The reversed flow creates a pull rather than push approach to manufacture and changes the dynamic of the system to focus on the whole system's end-to-end flow.
In layman's terms, this means that each station on the production line is concerned with carrying out the request it receives as promptly as possible to ensure the next station ahead of it is also able to do so.
Each station only carries out the work when it is requested; this is the Just in Time (JIT) of lean manufacturing. In any time between servicing requests, the workers at the station can clean their station and prepare themselves for any potentially busy periods ahead. They can also use this time to see if there is anything they can do to improve their process.
It is the responsibility of the entire production line to smooth out any unevenness in the flow. Workers should not try to compensate by deliberately operating their station even though they have no work requests, as this leads to unnecessary overproduction and stockpiling of inventory.
How Kanban/Lean fit into the Agile movement
Kanban, although not technically an Agile method, shares many similar attributes. The Toyota Production System (TPS) was founded on the principle that people were at its heart:
"Employees are offering a very important part of their life to us. If we don t use their time effectively, we are wasting their lives." Eiji Toyoda
You may find some people are initially skeptical that it is possible to translate practices from Lean manufacturing to software product development. They argue that there are very few similarities between a production line and a software development process.
Production lines are doing the same repetitive tasks over and over again in sequence, which is often associated with a predictive planning approach. However, using Just In Time manufacturing, Toyota has created and evolved an approach that makes their assembly line much more responsive and adaptive than any other.
The Lean approach to process management has already strongly influenced the thinking of those who formed the Agile Alliance. Many of the methods the practitioners created incorporate aspects of Lean already, such as Scrum's use of the Scrum Board to make work visible.
XP and Scrum's use of iterations to manage the batch size and create JIT thinking about the requirements and implementation of software products. These are just a couple of examples of how Taiichi Ohno and his work with others at Toyota have influenced how we build software.
Introduction to the mechanics of Lean/Kanban
Here are the basic characteristics and features of Lean/Kanban:
Planning style: Lean/Adaptive
Delivery Style: Flow/Incremental
Iteration length: Doesn't have time-boxed iterations
Principles: Eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, see the whole
Roles: Not prescribed, existing roles
Artifacts: Kanban (message board)
Special features: Kaizen (Continuous Improvement), makes work visible, limits work in progress, work with your existing process, make policies explicit, evolves empirically
Lacks: A clear process framework of its own; instead it asks that we make our existing process visible and use the principles of Lean to improve it
There are no explicit roles defined by Kanban; assuming you have everyone necessary to do the job you've been asked to do, this is sufficient.
Start with your existing process. Map the workflow on a wall, making it visible so that everyone sees it. Use this sudden wealth of information on how your system works to makes changes and bit by bit evolve it into something that works better.
Getting started with Kanban
There are four steps to implementing Kanban within your team, which we'll cover in the following sections.
Step 1 – Make the team's work visible
This involves creating a board that reflects the current process the team uses to deliver software. The work that the team currently has in progress and the stage it's at also needs to be shown. The easiest way to do this is to write down each work item on an index card and place it in the appropriate area of the board.
For example, a Kanban board for a team with a simple workflow would look something like this:
Step 2 – Make the work policies of the team explicit
Teams often handle this by placing entry and exit criteria for each column to make them transparent. This will look something like the following:
The policies form what is commonly known as the Definition of Done (DoD). The DoD is a checklist that the team applies to each work item. It is a way for the team to ensure they've completed the work item to a satisfactory standard and therefore ensure they are the baking quality of their product.
Step 3 – Improve flow
With Kanban, as with the other Agile approaches, we want to add value as soon as we can, by delivering useful software as fast as possible. The reason for this is two-fold:
1. Most people don’t know what they need until they see it. It's hard to imagine how the software will look and behave until it's built. Everyone has a different version of it in their head. Once you have something working, you can start to get feedback from your customer. This is when the real work begins.
2. The domain we’re operating in is rapidly evolving. In business terms, 6 to 12 months is too long to wait for something. The way the business works and the rules that govern it could have easily changed within such a timeframe.
For work to start to flow across the board, we have to do two things:
1. The first step is to reduce the size of each work item so that it is as small as possible. Taiichi Ohno called this reducing the waste of unevenness (Muri).
For us in the software industry, unevenness is reduced by managing and reducing probable variability, which we can also manage by keeping the work item as small as possible. This doesn't mean that we're eliminating all variability, just reducing the amount.
2. The second step is to switch to small batches. This can either be done as Scrum or XP does, using Sprints or Iterations.
Alternatively, the more granular way is to start to manage Work In Progress (WIP) limits so that the team can focus their effort on the items currently being worked on and avoid the loss of time caused by context switching when multitasking.
Assuming the items have been prioritized by value, this allows them to focus on completing the high-value items first.
Rather than thinking and working in iterations, the focus in Kanban is on optimizing the flow of work items through the system. To optimize flow two shifts in thinking have to happen. Firstly, we need to think of the system as a whole, the end-to-end process from idea to delivery of that idea.
Secondly, instead of pushing the work through the system, we have to think of the system as pulling the work through it. When the system has the capacity, it pulls the next piece of work into it to be worked on.
This requires careful control; the aim is to avoid large batches of work that move as one cohesive block as this only encourages optimization at the local level. Instead, we carefully manage WIP and prevent overcapacity by limiting the number of items being worked on at any given moment.
To identify where you might have flow issues in your process, you can map your entire process out so that the entire process is explicit.
This is similar to a technique known as Value Stream Mapping, but where a Value Stream Map is a snapshot in time, modeling your Kanban board precisely to your Value Stream allows you to observe and iron out any problems in flow in real time.
The following shows a Kanban board where our team has mapped out every step of the process:
Visualizing your work in this way will soon help you identify when there is too much work in progress.
For example, the team using the Kanban board in the following figure have identified that they have too much work to test and this is causing a logjam:
Blocks like this can have quite subtle effects. One observed result of allowing work to accumulate is to put all of the work items in the column into a single batch. We can then create a single software deployment and carry out testing on all the items at once. We think this will create efficiency in our testing, which it may do at a local level.
However, with five work items in that column, the reality is that each work item will delay the others as we wait for testing to complete. If we find any problems with one or two them, the whole batch will be delayed and the overall flow will be significantly reduced.
To tackle this, determine if this is a one-off or whether a pattern is emerging. Either way it is important to take pressure off the people who are currently testing, by swarming on the work as a team. Once the workload is back to normal, the team can prevent this from happening again by placing a WIP limit on the test column.
Step 4 – Kaizen or continuous improvement
Once the team is up and running with the preceding three steps, the next thing for them to implement is Kaizen.
Kaizen is a Japanese word meaning continuous improvement. It is similar in concept to Scrum and XP's retrospective event. The team is encouraged to take time to reflect on their work regularly, and where possible identify improvements to the way they carry it out.
Choosing the right framework
It's no surprise that most Agile transformations start at the team level. Agile is a grassroots movement led by a bunch of software developers who knew, through their trials and tribulations, that there had to be a better way to build software.
In choosing the right framework for your team it will depend a lot on where you are on your journey.
If you're a product/project team, Scrum is the place to start. Especially if you're new to Agile, or if you have a mix of Agile understanding of your team members.
Scrum is simple to pick up because the framework gives you everything you need to get started. Plus, once you begin to master some of the basics of Scrum, it's easy to add practices which enhance your agility.
This is the path that we will follow in this blog, in it we will give clear guidance on how to build up our team's practice of Scrum.
What follows in this section is a commentary on the three methods we've just overviewed where we took a quick look at the similarities and differences.
Designed for small teams
All of the Agile frameworks described in this blog are designed for use by small teams. For Kanban, there is no prescribed team size, but if clear communication and coordination among team members is needed, then keeping the team size small is desirable.
An Agile team's ideal size is often referred to as a two-pizza team, that is, the team is just big enough that two pizzas would be enough to feed it. This obviously depends on the size of the pizza!
They don't include product discovery phases
The other thing you'll notice about each of these frameworks is they don't explicitly define phases for product discovery/ideation. Few Agile methods do, DSDM being the standout. Instead, most prefer the team to manage this themselves. There are a number of techniques for doing so, including Design Thinking, User Story Mapping, and Impact Mapping.
Not all frameworks prescribe technical practices
Scrum, for example, doesn't specify technical practices. It's rumored that it did initially, to make the framework more effective, but Ken and Jeff pulled them before formally announcing it.
As a result around 10% of Scrum teams, according to VersionOne's 11th Annual State of Agile Report, incorporate some or all of the technical practices from Extreme Programming (XP).
There are similarities with subtle differences
Scrum and XP both explicitly involve the customer, Scrum with the Product Owner role, XP with the customer/business representative on the team. Lean Software Development emphasizes people are at its heart.
Scrum doesn't explicitly mention release planning, it assumes that the Product Owner will manage the backlog and the items nearest the top of the backlog are the ones of most value to the team. It assumes that the Product Owner will manage the backlog and the items nearest the top of the backlog are the ones of most value to the team.
Scrum and XP form batches of work using iterations. XP encourages its practitioners to err towards the smallest iteration possible.
This stimulates incremental delivery thinking and moves teams away from the pitfalls of a mini-waterfall, where you execute a User Story in a series of handoffs just as you would a waterfall project.
Kanban doesn't make use of iterations to batch work. Instead, it focuses on flow; achieved by keeping each work item as small as possible and by limiting the work in progress so that people can focus on one task at a time.
It is designed to work with your existing process, and because of its value-driven mindset, it will start to shift the Development Team's thinking towards delivering something sooner rather than later.
The advantage of using Kanban at a more granular level, work item versus iteration, means that we can be even more adaptive and responsive to change. However, with great power comes great responsibility, and the Kanban approach does require more attention to detail.
For example, to remain this adaptive requires that the customer and team have an innate understanding of the overall objective and whether they are currently tracking towards it.
I often hear people discussing where and when you should use Scrum versus Kanban. For example, because of Scrum's history in product development, it seems the logical choice when developing a new software product or making significant enhancements to an existing one.
For most people, Kanban seems better suited to a more ad hoc backlog, where it is typically little or no coherency between work items. This is often the case when the product is in maintenance mode (some would call this BAU or business as usual).
However, we shouldn't let Kanban's apparent simplicity fool us; of the two approaches, Scrum and Kanban, Kanban is probably the more nuanced.
Tightening Feedback Loops in the Software Development Life Cycle, it can be used just as effectively as Scrum to build products, if not more so. Applying Lean thinking to product development increases flow and works particularly well when the top portion of the Product Backlog is prioritized and well defined.
Mixing and matching Agile methods
As we’ve seen in this blog, there are a lot of similarities between Scrum, XP, and Kanban. No matter where we start as a team, most will start to combine the practices and thinking of one or more of these methods.
Sometimes we do it without realizing, for example, XP’s User Stories have become a universally accepted way to gather Agile requirements. Sometimes we do it explicitly because we want to enhance our Agile adoption with the benefits of a particular practice. An example is when Scrum teams enhance their workflow using Lean principles, Tightening Feedback Loops in the Software Development Life Cycle.
When we look at the practices that each method presents, we see a spectrum form. At one end of the spectrum, we have Kanban, a simple but nuanced approach for making work visible and then improving our workflow.
At the other end, we have XP, where years of practical experience led the founders of that movement to insist on following a specific, disciplined approach. XP can be too extreme for some as there are a lot of practices to adopt.
Lean Software Development and Kanban could be seen as too light—just do what you're doing now, but make it visible and seek to improve it by continuously eliminating waste in our process. Sounds simple, but understanding and optimizing our system isn't as easy as it sounds and requires much practice.
Scrum can be seen as somewhere in the middle. It provides enough of a framework for people to start their journey to becoming great inspectors and adaptors. At the same time, it holds back from prescribing a huge change in technical practices that may cause change phobia.
So, start with Scrum and get used to incremental delivery. Then begin to apply good disciplines that bake quality in from the beginning rather than test for quality later. Do this by conducting a number of experiments to see what works for you in your context.
One final thought, we need to consider that most Agile frameworks focus on the delivery of software. Few include explicit phases, either at the beginning for the initiation of product ideas or at the end of release and deployment.
The modern Agile movement is the coming together of three different timelines from the software industry's industrial heritage: Product Development, Engineering, and Lean Manufacturing.
We looked at the three most popular Agile methods, and how they represent each of these timelines.
We discussed how all three methods have a degree of crossover or similarity. For instance, Scrum encourages a high degree of transparency, and Scrum teams often communicate this using a visible workspace.
This is very similar to the concept in Kanban of making work visible. We also discussed how many companies are improving their results by mixing and matching from two or more approaches.
Introducing Scrum to your Software Team
This blog aims to get your new team up and running with an Agile delivery approach as quickly as possible. To do this, we'll use the Scrum framework to show how you can successfully transition a new-to-Agile team to this method of working.
We’ll use a pragmatic approach, based on real-world examples, offering the steps that you'll need to take.
We will cover the following topics in this blog:
Why Scrum is an excellent place to start
How to efficiently transition to Scrum from Waterfall
Visible workspaces for managing software delivery
Measuring and reporting progress with visualization
Managing delivery as a team sport
The importance of team retrospectives
In the last two blogs, there was a lot of theory, now; it's time for the practical guide to begin, and for the navel-gazing to stop. In this blog, we'll look at how to get your team up and running with Scrum. We'll go through the steps you need to take for you to transition from predictive to adaptive, and from gate to iterative.
At the end of this blog, your team should have completed its first Sprint. You'll understand that to be successful, managing the delivery of a software product has to become a team sport and not just the responsibility of one person (the person we used to call the project manager). You'll also gain a clear idea of how visible workspaces will help you achieve that.
We'll also describe several ways that you can measure the team's progress during the Sprint to help keep them focused and purposeful.
Why Scrum is an excellent place to start
Scrum is a lightweight framework that provides the necessary mechanisms to get your team's mindset focused on the essential aspects of Agile software delivery. If you were to compare learning how to use Agile to learning to ride a bike, then Scrum could be seen as the training wheels that get us moving forward.
That's not to say that Scrum is over-simplistic; as the saying goes, it's easy to learn but will take a lifetime to master. So while Scrum provides enough of a framework to get us started, it will also set us on the path to developing an Agile mindset.
So, Scrum is a perfect place for an Agile team to start its journey. It is by far the most popular framework amongst fledgling Agile teams. This blog aims to introduce the Scrum framework in a way that will help you to successfully transition a new-to-Agile team to this way of working.
Iterations and iteration length
Scrum is an iterative, incremental delivery process. Each iteration, or Sprint, as they are known in Scrum, lasts between a minimum of 1 week and a maximum of 4 weeks, with the preference being for as short as possible.
Shorter iteration lengths are what give our team its agility, as we get feedback at the end of each iteration; the sooner we get feedback, the faster we can adapt our approach.
If your team is new to working iteratively, there's no denying that it will feel odd at first. Based on experience, my recommendation is that your team picks an iteration length that feels slightly shorter than comfortable.
Taking this approach will give your team an opportunity to improve their process so that it fits the iterative style, and challenges them to change up their thinking.
What this means is, if you think 4 weeks is comfortable in which to deliver a working increment, choose 2-week iterations. If you believe that 2 weeks would be more than comfortable, opt for 1-week iterations.
The Scrum team should fix the iteration length, so pick an iteration length and stick to it. If after six iterations it isn't getting easier, then perhaps change the iteration length. Remember, the preference is always for the shortest iteration length possible.
Most teams I've worked with will opt for a 2-week Sprint, with teams occasionally choosing a 1-week Sprint if they feel they can achieve something meaningful in that time. It does depend on the context, but in general, my experience has been that 4 weeks is too long to wait for feedback.
Starting a new Scrum team
A word about time-boxes before we start: all Scrum events are time-boxed. For those that are formally part of the Scrum framework, their time-box recommendations are in the Scrum Guide.
All other activities or events that we introduce, such as Product Backlog refinement, should also be time-boxed. For these time-boxes, the facilitator of the event should estimate how long they think they need. They declare the time-box at the beginning of the event as part of the setup.
If you hit the time-box and you still have work to do, you can ask the team what they would like to do. Should they carry on, and if so, for how long? Should they reconvene at another time, perhaps?
Remember, meeting fatigue is a real thing, and people may have other commitments. Finding out if they can commit more time to extend the time-box is only polite, plus it's also an opportunity to sense the feeling in the room. If the energy is low, it may be worth taking a break.
To kick off a Scrum team, you'll need a few items:
A timer: This is used for time-boxing meetings; most smartphones have one of these
Whiteboard or wall space: This will be used to create your visible workspace
Tape for marking columns or swim lanes: If you're using a whiteboard, electrical tape works well; if you're using a painted wall, you'll need to use low tack tape, such as masking tape
Index cards: These are for writing User Stories post-it notes: These are for writing User Story tasks
If you're putting post-its straight onto a wall, not a whiteboard, buy the post-it® Super Sticky variety. They have much more sticking power and will save you from having to pick post-its off the floor and trying to figure out where they came from.
Black sharpie pens (fine tip): These are used for writing User Stories and tasks
For those moments when you don't have a spare whiteboard but need to write for the whole team to see, use a post-it 559 Super Sticky Easel Pad. These are sticky too, so they can be torn off the pad and stuck to a spare wall or window. And no, I don't have shares in 3M (the makers of post-its), but perhaps all Scrum Masters should.
The previous suggestions form a basic Agile toolkit, which each Scrum Master should have. I keep my own toolkit in a clear plastic fishing tackle box.
Preparing to Sprint
Before we start our first Sprint, we'll need to do a little housekeeping first. The primary focus is to make sure we have everything set up for the first Sprint Planning session.
The following activities are set up for team participation. Involving the whole team is the first step in creating a shared understanding and ownership of the product we're building.
Also include stakeholders for a well-rounded picture. Including those with a vested interest in your product will enable you to get their input from the beginning, starting the relationship as you mean to go on.
Here are the pre-requisites for carrying out this series of activities:
What you'll need: Index cards or A5 paper, post-it notes, black sharpie pens
Setup: A large table to work on that the whole team can fit around
Remember: Set a time-box before you start
We begin by first making sure that our Product Backlog is in order, which we'll do using the following activity.
Activity – defining the Product Backlog
One of the hardest parts of our transition to an incremental delivery approach is breaking down our team mission (the problem we're being asked to solve) into manageable chunks of work that will deliver working software.
Fortunately, there are several techniques for creating a backlog from scratch; these include User Story mapping and impact mapping. Both focus on maximizing the value we deliver to our customer.
For now, we'll assume the Product Owner has already created a set of User Stories for us to release, plan, and refine.
Have the User Stories written out on index cards, one User Story per index card? If you're using an online tool like Jira, print each User Story on a sheet of A5 paper.
Having a physical backlog in the form of a deck of index cards has several benefits:
It allows you to lay out the backlog easily to see the bigger picture.
It's tactile; something you can touch, pick up and examine, or easily move By shuffling the order, you can create multiple planning scenarios.
You can easily stick the stories on your Scrum Board, and turn them into a key part of your visible workspace.
Throwing the completed User's Stories in a cardboard box at the end of a Sprint and watching that pile of done stories grows iteration after iteration is very rewarding
Activity – release planning
Simply put, release planning is a process in which we determine what order we should implement the User Stories from the Product Backlog. Remember that our aim is to create customer satisfaction through early and continuous software delivery, the first Agile principle.
When creating a Product Backlog, it's easy for it to become a bit of wish list. Blue-sky thinking happens as part of any requirements gathering process, regardless of the technique used.
Release planning allows us to prioritize the User Stories; the aim of prioritizing a Product Backlog is to surface the stories that will bring the most value and satisfaction to our customer first.
It's entirely plausible that your Product Owner has already prioritized their User Stories. If not, the following are a couple of ways that the team can prioritize the backlog together.
If you do choose to prioritize as a team, who should be present? Well, you'll need your Product Owner. If the Product Owner would like to include key stakeholders, you should include them.
Finally, I would recommend including the entire team. I'm always surprised by the amount of information about a product that surfaces during release planning, and your team will benefit hugely from hearing it.
The following activity is a group approach to prioritizing User Stories:
What you'll need: The Product Backlog deck, post-it notes, black sharpie pens, and Spare index cards
Setup: A large table to work on that the whole team can fit around
Remember: Set a time-box before you start
Moscow is a simple but effective way to prioritize the backlog based on business value and risk. It is an acronym that stands for M: Must have this
S: Should have this, if at all possible
C: Could have this if it does not affect anything else
W: Won't have this time, but would like to in the future
The lowercase "o"s are needed to make the acronym pronounceable. If it weren't pronounceable, it wouldn't be an acronym, it would just be an initialization.
The Must User Stories are non-negotiable—if you don't deliver them, then the product won't work and it will be a failure. It's nice to have features classified as either Should or Could. The Won't classification doesn't mean that you won't ever build this functionality, it just means it won't be part of the first release.
The simplest way to play Moscow is to set up the table in the following way:
Follow these steps to release plan and prioritize the backlog:
1. Lay all of the User Story cards out on the table and give people time to familiarize themselves with the User Stories. Set a time-box appropriate to the number of stories. This step can be fairly social, people may share stories, or even read them aloud.
2. Next, we prioritize the stories, you should ask people to silently work and move the User Stories into the categories they think are the most relevant. Again, set a time-box for this.
Some stories will get moved and then moved again. Most stories will end up in the Must category to start with, and the table will likely look as follows:
If this situation does arise, remind people that this isn't in the best interests of the product's development. While User Stories marked as Won't be equally important as those in the Must category, deferring some work allows the team to get on with other features sooner.
To help this thought process, you need to think about which features might deliver the most business value or will reduce risk and uncertainty the quickest.
Ask the team which User Stories in the Must category can be moved down while still producing a coherent first release. Ask for suggestions of which stories you definitely Won't need, and then place them in Won't. Remind people that this is just for the first release.
After two or three iterations, you should see something like this:
Take the opportunity to review the User Stories and make sure you have a coherent set of stories for the Must swim lane. If it helps, order the stories from left to right in their logical sequence.
The User Stories in the Must swimlane are your first release. While this won't necessarily represent a complete set of features, once built, it will give you enough to gather good feedback from your customer, and as such, will act as the beginning of your product's lifecycle.
You'll almost certainly identify additional stories during this stage, so it's important to have extra index cards and sharpies nearby.
Another fun way for the team to work is with Buy a Feature. Buy a Feature is a game where team members are each given a certain amount of money.
You start by pricing all of the features, making sure that some are more expensive than one person can afford, and only a group can purchase them.
The object of the game is to decide as a team which features you deem most important for your product and need to buy. To do this, you have to collaborate and pool your resources. This game and how to play it is detailed in Luke Hohmann's blog, Innovation Games.
Activity – introducing the Product Backlog
The first step in this activity is used to familiarize your team with the Product Backlog:
What you'll need: User Stories written on index cards or printed, post-it notes, and black sharpie pens
Setup: A large table that the whole team can fit comfortably around
Remember: Set a time-box before this activity starts
The first step in this two-part activity involves your Scrum team sitting around the table. Your Product Owner has the Product Backlog; they pass it to the team member on their right. That team member takes the top story and reads it aloud, including the acceptance criteria and any notes.
They then place it in the center of the table so that other team members can read it, ask questions, and discuss the acceptance criteria. You should make any refinements to the story, usually in the form of pencil or post-it note additions.
Once the discussion is complete, the User Story will remain on the table, and the Product Backlog is passed right to the next team member, and the process is repeated.
This activity completes when either the backlog has been worked through or the time-box is over—whichever comes first.
As a general rule of thumb, it does help if your Development Team has seen the User Stories before they have to consider them during Sprint Planning. Giving your team chance to digest what needs to be done to achieve the User Story will give them greater confidence when planning.
Activity – estimating User Stories on the backlog
The second step in this activity is to estimate the stories on the backlog.
Activity: Using estimate buckets to size User Stories
What you'll need: User Stories written on index cards or printed, post-it notes, and black sharpie pens
Setup: A large table that the whole team can fit comfortably around
Remember: Set a time-box before this activity starts
Once you've had the chance to review the backlog, the second step is for you to refine the User Stories further.
A good place to start any refinement is to try to estimate the stories. When you ask for an estimate, it immediately triggers the thought process, "what do we need to do to complete this story?"
The ensuing conversation from your team will give a good indication if the objective of the User Story is clear and the acceptance criteria are well-defined.
If they aren't, you won't be able to estimate the User Story and the team will need to go through a series of refinements with the Product Owner before they are ready to try to estimate again.
Bearing that in mind, and also taking into consideration that not everyone has used relative sizing before, we'll take the following approach:
Spread the stories out on the table and take the time to read them and ask questions if necessary. You may refine the User Story or add acceptance criteria at this stage if you wish.
The next step is to take another User Story from the unsized pile and compare it to one of the stories you've already sized. We should ask ourselves the following:
1. Is it double the effort or more of the already sized story?
2. Is it half the effort or less of the sized story?
3. Is it a similar effort?
Our team places the story in the appropriate column relative to the already-sized story. You then pick the next story and compare it to the already-sized stories.
You decide if it's bigger, smaller, or similarly sized to the currently placed stories. You then put it in the column that's most appropriate and pick the next story card and repeat the process.
At this point, you should take a step back to admire your work and to decide if you've got it more or less right. Remember that relative sizing is less about precision and more about gut instinct, and most importantly, it's about team agreement.
Once your team is happy with the relative sizing of each story, write its size on the story card in the bottom right-hand corner, as per the following example:
Activity – setting up the Scrum Board
The Scrum Board is the team's information radiator. It enables them to communicate Sprint status with little or no effort, even to people outside of the team. The visual nature of the Scrum Board can also give teams an insight into how they might improve their approach.
Make sure that you leave enough space in each column regarding width and height. It may be a good idea to use an actual index or story cards and post-it notes to make sure you have enough room.
Discussion – Sprint Zero
At the beginning of a new piece of work, some teams will choose to run a Sprint that focuses purely on setup first. These can include anything from the Scrum Board through to source code repositories, Wikis to staging, and even production deployment pipelines.
This Sprint is often called Sprint Zero, although it is not officially recognized or sanctioned by the Scrum guide. Sprint Zero does deviate from the Agile Manifesto in that it delivers little or no working software at the end of it.
It's also not uncommon for teams to try to expand the Sprint Zero well beyond the usual iteration length—5 to 6 weeks isn't uncommon. This is a sign that the transition from a Waterfall-style delivery to an incremental one is too difficult for some to make.
As a coach with experience, this feels like procrastination. Sprint Zeroes can be used by teams as an excuse not to transition to an Agile approach, but instead stay comfortable with what they know. In this case, procrastination is a form of applied anxiety.
The one thing that I can honestly say is that if we always stick with what we know, we may never discover if the alternative is better. It's important that we experiment and are not afraid to fail.
Scrum is an empirical process, so 'failing' is more of a discovery of what works and what doesn't!
Instead of using Sprint Zero, treat the tooling and infrastructure that you need to set up just as you would each feature: deliver it incrementally.
You can do this either as part of each feature, by looking for User Story candidates in which you can include infrastructure setup, or by defining small User Stories that can be interwoven into your Product Backlog alongside feature delivery.
For instance, the first User Story will likely include setting up the source code repository and creating an initial deployment pipeline to a staging environment. Subsequent User Stories will likely include logging and enhancing the deployment pipeline to point to a production environment, and so on.
If you treat your infrastructure setup as you do your feature delivery, you can maintain maximum flexibility by delivering just enough to move forward. To avoid making assumptions, we need to solve the problems we have now, not the problems we don't have yet.
Day one of the Sprint
Now that we have our backlog in order and our Scrum Board set up, we're ready to start our first Sprint. This leads us to our first event of each iteration cycle: Sprint Planning.
Event – Sprint Planning
For Sprint Planning, you'll need the following:
What you'll need: The Product Backlog, post-it notes, and black sharpie pens.
Setup: A large table that the whole Scrum team can fit comfortably around. Time-box: A maximum of 8 hours for a 1-month Sprint; for shorter Sprints, the event is usually shorter. For a 2-week Sprint, a maximum of 4 hours should be sufficient.
There are two questions essential to Sprint Planning. The first is, "what are we able to achieve in this Sprint?" and the second is, "how will we achieve it?".
What can we achieve in this Sprint?
During this first phase of Sprint Planning, we focus on what we think we can compete in the coming Sprint. It is a forecast by our Development Team that determines which User Stories can be included in this Sprint Backlog.
The Product Owner and the Scrum Master aren't allowed to participate in the forecast as such, but they will be advising the team on User Story details and what their priorities are.
Starting with the backlog in priority order, and in a similar way to Product Backlog refinement, present the first story card to your team. The story card should be read aloud and then placed in the center of the table. Your Development Team should then decide if the User Story is achievable as part of this Sprint.
You should continue selecting story cards from the top of the backlog, reading them out and placing them in them on the Sprint Backlog until your Development Team thinks they won't be able to achieve any more in this Sprint.
At the end of this stage, you will have a line of User Stories sitting in the middle of the table, ordered from top to bottom in priority order.
How will we achieve it?
During the second phase of Sprint Planning, the aim is for the Development Team to determine how they will complete their Sprint Backlog.
Starting at the top of the Sprint Backlog, you should consider how you will implement the User Story.
To do this, use post-its and sharpies and break down the User Story into tasks. A lively discussion among your Development Team should ensue as you discuss how to implement this User Story. Write each task on a post-it note. Attach all tasks to the story.
Once one User Story is complete, select the next story from the top of the Sprint Backlog and do the same.
You should consider the Definition of Done (DoD) as you perform the task breakdown. You don't need to explicitly state items on the DoD as tasks. Instead, you should post the DoD on your Scrum Board so that your team can reference it and ensure they're following it as they implement the Sprint Backlog.
This phase is complete when the team has broken down all the stories into tasks. Your Scrum Master should count the total number of tasks so that they can create the Sprint Burndown chart.
Sprint Burndown tracks the number of tasks remaining. After each Daily Scrum, the Scrum Master should count the tasks remaining and update the Sprint Burndown.
Don't be alarmed if it tracks up before it tracks down; we often discover new information when we start working on a User Story, and so new tasks will inevitably be added.
The Sprint Goal
The final step is for your Product Owner to define the Sprint Goal, an overarching objective that can be met by the Development Team that should provide them with guidance on why they are building the next increment.
It should be a short statement, such as, "Implement a simple checkout that allows credit cardholders to purchase items in their cart".
Try to keep your Sprint Goal concise, as this will help your team focus on building the right thing. The Sprint Goal should help you decide if our work is contributing to the outcome your Product Owner is seeking. One thing it should not be is a "laundry list" of work or even a list of User Stories that your team needs to complete.
Event – first Daily Scrum
The Daily Scrum is a time-boxed meeting which lasts 15 minutes. Following the tradition of Extreme Programmers (XP), most Scrum teams stand for the duration. Standing helps keep the meeting short and to the point because you're less likely to chat.
Here, your team gathers around the Scrum Board.
Each Development Team member takes it in turns to answer the following three questions:
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal? Do I see any impediment that prevents the Development Team, or myself, from meeting the Sprint Goal?
One way for a team member to communicate what they are working on is for them to stand next to the board and point to the User Story or task.
For the very first Daily Scrum, you probably won't need the first question, unless you've already started work on meeting the Sprint Goal.
In the first Daily Scrum, you should be more focused on who is going to work on what, and ultimately how the team will work on things together.
The Scrum Master should keep an eye on the time-box, as its possible, the 15 minutes will pass by without notice.
It's worth getting into the habit of taking it in turns to answer the three questions, listen to any updates or feedback from the Scrum Master or Product Owner, and then recognize that the Daily Scrum is officially over.
The Scrum Master should update the Sprint Burndown chart, which measures the total number of tasks left to complete. You can then have any breakout sessions, where two or more team members may get together to discuss issues in more detail.
Some teams call the breakout session after the Daily Scrum the "after party". Some teams even go as far as recording what needs to discussed at the "after party" by making notes during the standup.
For examples of this and other visualization ideas, see Jimmy Jansen's blog, Toolbox for the Agile Coach - Visualisation Examples, Leanpub.
A day in the life of a Scrum team
Each day at the specified time, the team meets at the Scrum Board for the Daily Scrum. Once the Daily Scrum is complete, the team may then catch up with each other to discuss certain work items in more detail, or perhaps to demonstrate the work completed so far to the Product Owner to see if it's heading in the right direction.
Working as a Scrum team requires a coordinated effort that will often extend beyond the Daily Scrum. It's not often that team members operate in isolation from one another. Co-locating your team means you can pick up from the environment how others are progressing, even if people are working individually on a task.
You'll often find Scrum team members completing work before the next Daily Scrum, who will need to find another task on which they can work. If necessary, they can call an impromptu standup around the Scrum Board to discuss things with the team and make sure they are selecting the right thing to work on.
It's also important to keep focused on the Sprint Goal, and you should ask yourselves regularly how confident you feel in reaching it. You could do this as often as every day, for example, at the end of every Daily Scrum.
One technique we could use for this is called Roman Voting, where you use your thumb to indicate your vote: either up for yes, you're confident, down for no, you're not convinced, or sideways for you're on the fence.
If the majority of team members are not feeling confident or are on the fence, then you should encourage talking as a team to determine if there is anything that can be done to improve confidence in completing the Sprint Goal.
To help determine what course of action to take, you can use visual techniques to help enhance your understanding—something we'll look at in the followings section.
Measuring and reporting progress with visualization
The Scrum Board itself gives a clear picture of how a team is tracking. It's immediately apparent which User Stories are in progress, and on which tasks the team is busy working.
It's possible for us to enhance the information that the Scrum Board radiates in ways that will make the status of the Sprint more evident, and therefore the conversation at the Daily Scrum less about the team's status and more about the work and coordinating around it.
The following subtle visual additions should allow you to reduce cognitive overload, enabling the team to focus more on the work at hand and less on managing the process around it. Of course, these are just suggestions; if you can think of any others, then by all means experiment.
Create avatar cards to represent each team member. A picture stuck on a card backed with wall tack will work; laminating them will increase their longevity. You can then place these on a board to represent which task team members are working on, as in the following figure:
This shows that one team member is working on the third task of the first User Story. Two other team members are working the second task of the second User Story. Using avatars reduces the time taken at the Daily Scrum, as when each person talks, it's clear what they are working on.
It also helps to coordinate work outside of the Daily Scrum. For example, when looking for their next task, if a team member can easily see who is working on a User Story, they can coordinate with those team members.
Done stickers are simply post-it notes with the word DONE written on them. We place them on a User Story to show that it's done—meaning that all work is complete, including those items on the DoD. The following figure shows a 'DONE' sticker on the first User Story:
At the end of Sprint Planning, after the team has broken down User Stories into tasks, the Scrum Master totals up the number of tasks in the Sprint Backlog. The Scrum Master then creates a Burndown chart.
The following diagram shows a Burndown for a Sprint already in progress:
The y-axis represents the total number of tasks. The x-axis represents the number of days in the Sprint.
The red line on the following Sprint Burndown chart represents the number of tasks left to complete.
The dotted line represents the Ideal Burndown rate in order to complete all tasks by the end of the Sprint; as you can see in the preceding figure, the red line (the Actual Burndown) hasn't decreased in the way we expected.
In this case, the Actual Burndown shows that new tasks were discovered when the team began working on a User Story, and so the total number of tasks has increased. It is not unusual to uncover new information once work commences.
Sprint Goal confidence
In the previous section, we looked at how to run the first Daily Scrum event. We discussed that a Daily Scrum was a good place for a team to review if they felt they could still meet the Sprint Goal by the end of the Sprint. We used Roman Voting to express our level of confidence.
The following figure shows thumb icons on the Sprint Goal; we've used them to record each team member's vote so that we can see from Scrum-to-Scrum how things are changing.
We can use this to decide if we need to do anything to improve the process. For example, if there is a sudden drop in confidence, perhaps it's worth re-planning the approach to completing the Sprint Goal:
The importance of visible workspaces
Making work visible in the form of a Scrum Board is one of the most empowering features of Scrum.
We often call visible workspaces information radiators because they radiate information to anyone within sight of them, as shown in the following figure:
Scrum Boards enable several things to happen:
1. A visible workspace allows a team to debug its process like never before. A team can stand back and take in a complete picture of a Sprint's progress. If you're new to Agile, this gives you information that you've never had before.
The visible nature of the work in progress enables you to make better decisions. It's not uncommon to see Scrum teams gathered around the board outside of the Daily Scrum, assessing the state of play and deciding what to do.
2. Stakeholders can also easily assess the work in progress by visiting the Scrum Board. This results in fewer interruptions to the Scrum team.
3. Transparency leads to easier risk management. At a glance, you can determine if an item in progress is blocked and needs assistance, and from the wider perspective, if you're likely to meet the Sprint Goal.
In a non-Agile environment, this information is usually kept online in a project planning tool or spreadsheet, making it less visible.
Online tools can be useful, especially when used for tracking trends over time or when people work remotely. However, we often call online tools, such as Jira, PivotalTracker, Rally, or Trello (to name a few), information refrigerators because although they store information well, it's hard to see.
You have to go to the fridge, open the door, and poke around. Often, the thing you're looking for is down the back, covered in ice and hard to spot.
The tools that enable you to do this easily are your visible workspaces; in other words, your Scrum Board and your work which is made visible on it.
Using the Scrum Board, you can easily track the progress of your User Stories and their related tasks. The completion of a task also feeds into your Sprint Burndown, giving you an idea of how close you are to completion.
Part of the Scrum Master's role is to remove any impediments that are in the way of the team carrying out their work. It's sometimes hard for team members, particularly those new to Scrum, to recognize what is and what isn't an impediment.
For example, if you're waiting for your operations team to set up a staging environment for us to perform user acceptance testing and everything else has been done to this point, then this is impeding the completion of this work.
However, the team might not view this as a problem because it's just the way things have always been done. The Scrum Master has to start to develop a nose for this stuff in order to smell real impediments.
We use the term smells as a metaphor because, just as in real life, the cause of a smell isn't always what we think it is. Using the term 'smell' allows us to sniff out a potential problem without jumping to conclusions or laying blame.
If our nose turns out to be correct, we can help our team avoid any nasty bumps in the road. If we're wrong, then it's better safe than sorry.
Bad smells for a Scrum Master include, but aren't limited to:
A team member talking about something they're working on that isn't visible on the Scrum Board
A team member not speaking at the Daily Scrum
A small task that should have only taken hours hasn't made any progress in a day or longer
The Sprint Burndown is tracking to target—normally, a Sprint Burndown tracks up before it tracks down; new tasks are often added when work on a User Story commences, so if the Sprint Burndown is tracking exactly to the expected burndown rate, something fishy is happening.
Managing delivery as a team sport
When transitioning to Scrum, you may notice that you'll be better able to manage your workload. When you think about it, this makes much more sense; the people who are actually doing the work are the people best placed to understand its progress and value.
When a team forecasts User Stories to be completed during Sprint Planning to create the Sprint Backlog, they're setting up an informal commitment with a Product Owner. Here, we're saying that we will complete this work on the provision that:
1. The Sprint Backlog remains fixed; there are no sudden changes such as altering priorities or swapping out stories.
2. We're given the time, freedom, and space to work.
If we're able to reduce interruptions coming into our Development Team as much as possible, it allows us to focus on what we need to do. Instead of asking a Development Team member to do something "urgently", an urgent task can be placed at the top of the Product Backlog, where it will be picked up in the next Sprint.
Giving a team this latitude within the Sprint boundary means that they will become better at self-management. In fact, they're much more likely to complete the work and achieve the Sprint Goal if they're allowed to determine how to best organize themselves.
Another factor to consider in the successful self-organization of a team is subtle control. For a Scrum team, decisions on what to build ultimately stop with the Product Owner, and these decisions are influenced rather than directed by the wider stakeholder group.
The last day of the Sprint
We will now conclude the Sprint with two events: the Sprint Review, followed by a Sprint Retrospective. Both of these events give us the opportunity to inspect and adapt the work we've carried out during the Sprint.
We always hold the review first because the conversation there is likely to spark further discussions and raise action points at the retrospective.
In the following two sections, we will describe how to set each event up and what to expect.
Event – Sprint Review
The Sprint Review's focus is on the increment of working software that has just been built and how successful the Sprint has been in moving the product's progress forward.
This is how you set it up:
What you'll need: A large screen to demonstrate your working software, the User Stories you've completed, the User Stories you didn't complete, the Sprint Goal, index cards, sharpies, and post-it notes
Setup: A large table that the whole team can fit comfortably around with a view of the screen
Attendees: The Scrum team and stakeholders Time-box: 4 hours for 1-month Sprints; for shorter Sprints, the event is usually shorter
The central focus of the Sprint Review is for your team to demonstrate the working software they've built as part of the Sprint.
They should decide upfront which member of the Development Team is going to show the working software. You may decide that it will be a group effort, in which case, you should decide which team members will show which of the completed User Stories.
The basic flow for the Sprint Review should be along the following lines:
1. The team member who is demonstrating the first complete story reads out the story card, including the acceptance criteria.
2. They then demonstrate the software and explain how it meets the acceptance criteria.
3. They then ask for any questions or observations.
4. The team member who is demonstrating the next complete User Story takes that story card and repeats the process.
The Sprint Review is an opportunity for you to engage your stakeholder group and gather feedback on whether the product is moving in the right direction. Of course, your Scrum Master and Product Owner should be able to recognize that this is the first Sprint and that the software you've delivered won't necessarily show a complete set of features.
Once all complete stories are demonstrated, the Sprint Goal should be read out by the Product Owner, and the team should discuss and review whether they've achieved all, part, or any of it.
The final part of the Sprint Review is to open the room to any questions or observations. For example, the invited stakeholders may be interested to hear what the team has planned next.
They may also be keen to offer feedback about the direction the team is moving in, or even suggest changes or a new direction. This feedback is likely to be incorporated into existing User Stories or may even create new User Stories.
The worst case scenario during a Sprint Review is that there is no working software to demonstrate, which can happen if a team hasn't completed any User Stories or if the working software is hit with technical difficulties. If this happens, the team should move directly to the Sprint Retrospective.
Take time to prepare for Sprint Review. It is a demonstration of working software, so the last thing you want is a case of non-working software. Make sure that you've got a working demo before you start.
Unfortunately, I've seen Sprint Reviews canceled on a couple of occasions because the team failed to get their software working. In these instances, there was a room full of stakeholders who left dissatisfied.
Event – Sprint Retrospective
The Sprint Retrospective is an opportunity for the team to reflect on their first Sprint. You should look at what went well, what didn't go so well, and what can be improved.
This is how you set it up:
What you'll need: post-it notes, black sharpie pens, and a whiteboard
Setup: A large table that the whole team can fit comfortably around
Attendees: The Scrum team
Time-box: 3 hours for 1-month Sprints; for shorter Sprints, the event is usually shorter
Your Scrum Master facilitates the Sprint Retrospective. There is a degree of preparation required to run a retrospective, and so we recommend heeding the following format:
Setting the stage: The Scrum Master presents some facts and figures from the last Sprint. They should aim to paint a picture of what happened. Did the team meet its Sprint Goal? What was the team's velocity? How did the Sprint Burndown look?
Gather data: At this stage, the team needs to collect more data about the Sprint. On the whiteboard, the Scrum Master draws quadrants for the four following categories:
What went well?
What didn't go well?
Ideas for change
Shout outs (thanking team members for their work)
Using post-it notes and a sharpie, write as many post-its as you can think of (one item per post-it) that fit into either one of those four categories. The Scrum Master will keep the time-box, and the team should work silently. They can then place the post-it notes on the board as they go or wait until the time-box is up.
Once done, you should end up with something like the following:
1. Generating insights: At this point, you should examine what everyone has written as a group. You can see, for example, that three people have mentioned automated testing in the 'Ideas' quadrant. You can also see that the team agrees that there are too many distractions.
2. Decide what to do: Next, you need to decide how to improve the next Sprint for the better. For this, you can either take an item from 'What went well' and decide how to amplify it.
You could also decide how you can minimize an issue from WHAT DIDN'T GO WELL. You could also work out how to implement an IDEA FOR CHANGE. Consider the items that will generate the most value.
The Scrum Master will ask the team to vote on what needs to be done. Team members get three votes each and each vote must be written on one post-it note.
In the following instance, we use gold stars to vote:
As you can see, AUTOMATED TESTS and LESS DISCUSSION AT STANDUP get three votes each in total.
So, now it's time to create actions for each of these. Aim to take two to three actions from each retrospective, and no more. You're aiming for small incremental changes that can be introduced with each Sprint. Your goal should be to make your actions SMART: Smart, Measurable, Agreed upon, Realistic, and Time-based.
Here are some suggested actions that fit the SMART approach:
ACTION: Less discussion at the Daily Scrum
WHAT: Set up an 'After Party Zone' on the Scrum Board. Any topics for discussion should be recorded there so that the team can talk about them in the After Party.
WHO: The Scrum Master will set up the After Party Zone area on the board and record any relevant topics.
WHEN: At subsequent Daily Scrums.
ACTION: Automated testing.
WHAT: Implement a test framework when working on the next story to facilitate learning.
WHO: Jono and Rupesh.
WHEN: The next Sprint.
3. Close: With the retrospective actions complete, the Scrum Master closes the retrospective. They ask each team member to give one sentence to describe their experience of the retrospective.
The Scrum Master will then place the retrospective action items on the team's Scrum Board to be worked on during the next Sprint.
Descriptions of the five stages of a retrospective that have been used here, including examples of activities, can be found in an excellent blog called Agile Retrospectives: Making Good Teams Great, by Diana Larsen and Esther Derby. This blog should be part of any Agile team's toolkit.
The importance of team retrospectives
Scrum is an empirical process—we're constantly learning what works well and what doesn't work so well. Scrum requires a team to inspect and adapt its process on a regular basis. In this way, the team can continuously improve its approach, sometimes making profound changes along the way.
Retrospectives are at the heart of this mindset; they teach us to reflect and improve. Just as we would debug our software, we are now learning how to debug our process.
It's important not to accept the status quo! There's always a better, and hopefully more satisfying, way to do something.
In this blog, we guided your team through their first Sprint. There were a lot of activities needed to get us this far, and to give us the right foundation for moving forward.
Remember that it will probably take four to six Sprints for a team to hit its rhythm. No matter how successful you are in delivering something at the end of that first Sprint, the important part is that you did it! You and your team have now successfully transitioned and can use an iterative, incremental delivery style.