DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

SBOMs are essential to circumventing software supply chain attacks, and they provide visibility into various software components.

Related

  • Feature Owner: The Key to Improving Team Agility and Employee Development
  • Variance: The Heartbeat of Agile Metrics
  • Sprint Retrospective Meeting: How to Bring Value to the Table
  • The Agile Scrum Ceremony Most Talked About but Least Paid Attention To

Trending

  • What Is Plagiarism? How to Avoid It and Cite Sources
  • Microservices for Machine Learning
  • The QA Paradox: To Save Artificial Intelligence, We Must Stop Blindly Trusting Data—And Start Trusting Human Judgment
  • Stabilizing ETL Pipelines With Airflow, Presto, and Metadata Contracts
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. A Typical Sprint, Play-By-Play

A Typical Sprint, Play-By-Play

In this article we look at the mechanics of a Sprint, and at how team members are expected to collaborate in order to produce a release-quality increment.

By 
$$anonymous$$ user avatar
$$anonymous$$
·
Mar. 01, 17 · Tutorial
Likes (8)
Comment
Save
Tweet
Share
7.2K Views

Join the DZone community and get the full member experience.

Join For Free

The First Day: Sprint Planning


The whole team, including the Product Owner, meet on the first day of the Sprint and conduct a Sprint Planning session. This is the very first thing to happen as soon as the Sprint commences.

Preparation

Sprint Planning ought to be prepared for. The most important preparation is to ensure that the Product Backlog has been refined to an appropriate level of detail, with estimates and acceptance criteria (this is the purpose of Product Backlog Refinement). Next, the Product Owner should have ordered the work on the Product Backlog, and have a general idea of how to negotiate a valuable Sprint Goal with the team. The options for negotiating a Goal should also have been considered during Refinement and reflected in backlog ordering. Also, the team should have an idea of their capacity for this Sprint, which is to say, how much work they believe they can take on. They may be able to use their experience with previous Sprints to help them ascertain the size of this budget.

First, Plan the Value That Will be Delivered

Each Sprint should result in a valuable increment of completed work, fit and ready for immediate release. The Product Owner is wholly accountable for what “value” means, and ought to have ordered the Product Backlog in such a way that value can be maximized by the team, sprint-by-sprint. The first thing the team must do, therefore, is to plan which items from the Product Backlog should be worked on in this Sprint so that the best value can be delivered by the end of it.

To do this, the team works with the Product Owner to select the most valuable items from the Product Backlog which fits their projected capacity for the Sprint. Bear in mind that each item on the Product Backlog ought to have been given an estimate by the team, so they will know roughly how much work is likely to be involved. 

Be Sure to Agree on a Sprint Goal

This selection of work should be cohesive, and not just a grouping of unrelated and disparate items. Remember that a Sprint is a time-boxed opportunity to achieve something significant. For example, by the end of the Sprint, a coherent feature may have been delivered, or a significant risk will have been mitigated. The Sprint Goal is a simple expression of this purpose, of the overarching significance of the work selected, and the coherence behind the selection.

A good Sprint Goal will allow the team to demonstrate focus and commitment, and allow collaboration and the re-planning of work so it is met.

Next, Plan How the Work Will be Done


A Sprint Backlog is more than just a selection of work with an end goal in mind. It is also a plan for how that goal will be achieved, and how the associated work will be performed. This can be done by identifying and ordering the technical tasks that are likely to be involved. In effect, the Sprint Backlog is a plan for meeting the Sprint Goal, and a forecast of the work that will have to be done.

The Product Owner does not need to be present for this part of Sprint Planning, as it is up to the team to plan this forecast at a technical level. However, the Product Owner should be available, even if only remotely, to answer any questions the team may have, and to provide any clarification that may be needed about the scope of the work. If more than one release is expected during the Sprint, this should be agreed with the PO and accounted for in the Sprint Backlog.

By the end of Sprint Planning, a team should be confident that it has made a good forecast of the work that will be needed to meet the Sprint Goal. It will have captured that plan in the Sprint Backlog which the team wholly owns. The team should be able to begin implementing that plan immediately and with a clear understanding – such as a Sprint Burndown - of how much work remains at any given point.

Each Day, Every Day


Once the team has planned their Sprint Backlog they can start work. If they have planned things out as tasks, they will collaborate with each other, as a team, to make sure that those tasks are completed. They’ll be able to track their progress by using their task board and their Sprint Burndown of work remaining.

Each team member will be sure to keep the Scrum Task Board and the Sprint Burndown updated, so the information can be relied upon by others. An information radiator should always tell the truth.

Hold a Daily Scrum

Every working day, at the same time, the Development Team will meet and plan what they will do to bring them closer to the Sprint Goal. This meeting is called the Daily Scrum, and it should never take more than 15 minutes.

Only Development Team members should participate, as the plan of work belongs entirely to them. It is a time-boxed opportunity to re-plan the Sprint Backlog as a result of new discoveries and lessons learned during the Sprint. The whole team should participate. Each team member should be able to account for:

  • What they did yesterday to help the team meet the Sprint Goal.
  • What they intend to do today to help the team meet the Sprint Goal.
  • Any impediments which are getting in their way.

By the end of the Daily Scrum, the team should have a clear plan for the next 24 hours, and an understanding of how they will need to collaborate in order to achieve it. They should also have a list of any impediments which require the Scrum Master’s attention.

Refine the Product Backlog


In Scrum, Product Backlog Refinement is not a formal event but an ongoing activity - the process of adding detail, order, and estimates to Product Backlog Items such as User Stories. It’s up to Scrum Teams themselves to decide how often to do this, although it’s certainly a good idea for them to build refinement into their daily routine. Refinement shouldn’t take more than 10% of a team’s total time during a Sprint. For most teams, half an hour a day may be adequate although some may prefer to spend an hour or two a couple of times a week. The important thing is to make sure that the Product Backlog is refined in a timely manner so that Sprint Planning can occur without impediment. The whole team, including the Product Owner, should participate.

A refinement session typically begins with the Product Owner presenting the current Product Backlog to the team. The backlog may be held in a number of forms, such as an electronic Scrum Board or another collaboration tool, or it may simply be a spreadsheet. A projector or shared screen can be very useful.

The team starts at the top of the Product Backlog and works their way downwards, refining each item in turn. They’ll examine each one and discuss its scope, and the acceptance criteria that will be necessary for its completion. Each item will then be estimated using a technique such as the Planning Poker. A large item may be broken down into smaller ones which capture greater detail. Epics may be decomposed into user stories, for example.

The team stops once the session’s time-box runs out. They will recommence where they left off the next time, eventually starting at the top again so the backlog is kept up to date.

Always Collaborate

In Agile practice, team members never work in isolation – if they did, they wouldn’t be a team. In fact, teamwork is so important that the role is Development Team rather than Developer.

This means that each Development Team member must collaborate with his or her peers throughout the day, as they are jointly responsible for the progress of the work. Any problems or failures are jointly owned by the team, as well as their successes. Collaboration is not something which is restricted to events such as the Daily Scrum but applies to everything the team does throughout each entire Sprint.

Examples of collaboration include:

  • Helping peers to complete work in progress before bringing in new work from a backlog.
  • Pair programming, such as taking turns using the keyboard and helping and checking each other’s work.
  • Peer review.
  • Asking for help, and being keen to give it.
  • Going to where the work is and helping, instead of waiting for work to be passed over to them.
  • Making sure that all work does, in fact, meet the Definition of Done.
  • Calling a Scrum in order to resolve problems which need the team’s immediate attention.
  • Raising impediments to the Scrum Master so they can be handled in a timely manner.
  • Updating a Scrum Taskboard and Burndown chart so that the information is up-to-date and can be relied on.
  • Skill and knowledge sharing.

The Final Day: Review and Retrospective

Hold a Sprint Review


If a team has collaborated efficiently, they’ll have worked together to meet the Sprint Goal, managing any risks, and adjusting their plans as necessary. They’ll have demonstrated control throughout the Sprint through an even Burndown of work remaining, where each member saw it as their personal responsibility to help complete work in progress. They’ll have a valuable increment to demonstrate to the Product Owner and any invited stakeholders. A Review is something a team should look forward to.

It’s also something a team must prepare for. Enough time must be allowed for a demonstration of the work which has been performed. Tasks may be planned on a Sprint Backlog for this purpose, to make sure that the Review does justice to the work done and the value which is now available. Also, if the Product Owner thinks it would be a good idea to invite stakeholders, then those invitations ought to have been sent. The review is an opportunity to celebrate the work which has been done and to showcase their accomplishments, so confidence is inspired and a continued investment in the team might be justified.

A Sprint Review is also an inspect-and-adapt opportunity. It’s a good time for the Product Owner to explain how well the product is performing, to get feedback first-hand from any invited parties, and to draw any lessons which might be used to improve the Product Backlog further. If any work has not been completed, for whatever reason, then this will also be reviewed and re-estimated on the Product Backlog for possible planning into future sprints.

Then Conduct a Sprint Retrospective


The Sprint Review looked at the Product and the value delivered, at the work which has been done, and honestly and candidly at any work which wasn’t done, whatever the reason.
The next thing to do is to conduct a Sprint Retrospective. A Retrospective considers the process which the team is following. Are they working as effectively as they can? It’s generally best to hold the Retrospective immediately after the Review because the former can introduce ideas for consideration in the latter.

The whole Development Team, the Product Owner, and the Scrum Master must all attend the Retrospective because everyone is jointly responsible for the success of the team’s work. It’s really important to have a free and open session which gets to the heart of any problems and identifies actions which will help to resolve them. A Retrospective may begin with the following declaration:

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

In a “Retro,” everyone has an equal voice. One approach, which the Scrum Master may facilitate, is to identify:

  • Things which went well.
  • Things which didn’t go so well.
  • Ideas for improvement.
  • Shout-outs for team members who did something exceptional.

Establishing a timeline can help jog attendees’ memories about significant events during the Sprint.

Sprint (software development) scrum agile

Published at DZone with permission of $$anonymous$$, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Feature Owner: The Key to Improving Team Agility and Employee Development
  • Variance: The Heartbeat of Agile Metrics
  • Sprint Retrospective Meeting: How to Bring Value to the Table
  • The Agile Scrum Ceremony Most Talked About but Least Paid Attention To

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • [email protected]

Let's be friends: