Thursday, August 30, 2012

Scrum tales - part 4

As a Scrum team you just finished your first Sprint and need to start a new one? Look no further and see below

Wrapping up a Sprint

1- Sprint review
At the end of the Sprint it is important to present the results to your Product owner in a Sprint review meeting. This meeting is informal in nature so to speed this up just send in Sprint summary email specifying all Product backlog items (goals) and their status:
   a) Done - good, make sure that Product owner can see the results
   b) Not done - explain why the goal wasn't achieved

In the case of #b, reasons can vary from having a surge of ad-hoc tasks interfering with the Sprint priorities, goals being blocked by external impediments, to Scrum team members being abducted by aliens; in any case the reason must be clearly explained. Having clear reasons stated will help both Product owner and Scrum team to adapt future Sprints to prevent this from happening or at least to plan ahead: plan more time for ad-hoc priority tasks, work out the impediments in advance, or prepare supplies and go underground in case of an alien invasion

Important: unfinished Product backlog items must be moved into the new Sprint if they are still of high enough priority and be 100% finished there

2- Sprint retrospective
This meeting is organized by the ScrumMaster and whole Scrum team should attend. It must cover the answers to the following questions:
   1. What worked?
   2. What didn't work?
   3. What will we do differently?

Log answers to the above questions in your Scrum tracking system and apply them in the next Sprint. It is necessary to adapt your self-organization as a team to prevent or predict impediments and make the next Sprint achieve all defined Sprint goals


Starting a new sprint

1) Make sure your team Product backlog is up-to-date; if you have uncertainties about Product backlog items or their priorities contact your Product owner early

2) Change ScrumMaster in the team - this is mainly up to your team to decide, but changing ScrumMaster will allow you flexibility and make sure anyone can handle the responsibility. It is not an excuse to stop sprinting if specific team member who knows how to be a ScrumMaster is away

3) Conduct a Sprint planning meeting with the whole team and prepare new Sprint backlog. Although Sprint backlog is ownership of the Scrum team and Product owner shouldn't interfere, still send the final variant in an email for Product owner to see and to at least have a reference when discussing any future related issues

No comments:

Post a Comment