A Typical Sprint, Play-By-Play

The team start at the top of the Product Backlog and work 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 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 stop 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 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 it in turns to use 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 Task board 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