GETTING DOWN TO WORK WITH SPRINTS

Sprints are periodic cycles in which the team completes the work and makes it ready for review. The sprint backlog is a subset of stories from the release backlog. Each sprint begins with a planning meeting. The product owner proposes what she’d like to get done in the release, and then she, together with the team, select the items and size of the sprint backlog. The team should select the stories and commit to completing the tasks in the sprint.

Daily scrum meetings are held every day, and they usually last no longer 15 minutes. They are also called stand-up meetings, because the idea is to stand up during the meeting to keep it short. The team gets updated by answering three questions: “What did you do yesterday?”, “What are you going to do today?”, and “Is anything blocking your progress?”

Stand-up meetings are a daily opportunity to ask for help and to get closer to the team.

Sprint planning

KEEPING THE RIGHT PRIORITIES WITH BACKLOG REFINEMENT SESSIONS

A key aspect to maintaining the right priorities throughout the project is ongoing backlog refinement. The product owner should make sure, together with the team, that the backlog is up to date and prioritized, so that the work can flow easily into the sprints. Backlog refinement is one more way in which business needs can be continuously identified and prepared for delivery within a sprint.

REVIEWING THE WORK AT THE END OF THE SPRINT

Once the sprint is coming to an end, the team holds a sprint review session. During the sprint review, the team and Product Owner review the sprint’s work. Each story that’s accepted is moved to the “done” column on the board. Anything that isn’t accepted as complete gets reprioritized and moved out to another sprint or to the backlog.

Sprint review sessions are a great way for the team to track progress and check out what’s coming.

At the end of the day, the Product Owner has the final say on accepting or rejecting what’s been delivered. Whatever gets accepted, should be demoed to a larger audience. The demo serves to ensure the stakeholders are happy with the work done on their behalf. It’s a checkpoint designed to verify that what the team has delivered fits the customer needs. Holding regular demos and involving the stakeholders in the project not only creates trust; it’s also a way to get closer to a working product.

Last but not least, the team gets together after the sprint to discuss what worked well, what did not work well, and what can be improved. This is called the Sprint Retrospective, and it’s facilitated by the Scrum Master.