First Steps with Scrum

In my last post, I described the process of lift-off in Scrum based on my experience working with clients and teams in different organizations and with different types of products.  Now I want to describe what are the steps to follow now that the roadmap has been reviewed and approved by the Stakeholders.

These steps are fairly straight-forward since they are about kicking-off the Scrum Team and executing the first Sprint.

1. Scrum Training – after you complete lift-off, but before you begin with the first Sprint, it is my recommendation to have a training for the Team, Product Owner and the key Stakeholders.  Scrum has been around for a long time and people tend to define the roles, meetings, documents and vocabulary of Scrum based on their last Scrum project rather than the actual definitions provided by the framework.  Before beginning with your first Scrum project, it is important everyone be on the same page when beginning your project.  My minimum requirement is a Scrum training of one day.  This will be a complete review of the workflow, values and principles, roles and each piece of the framework.  If you cannot get one day, a half a day will be OK, but you can only cover values and principles, workflow and roles.  If an organization will only dedicate a few hours, I sadly explain they are not serious about doing Scrum and are better off using traditional project management techniques.
2. Define the Definition of Done – before starting Sprint Planning, the ScrumMaster needs to facilitate an agreement with the Team on what is their Definition of Done.  The Definition of Done is a checklist of activities each work item, or Product Backlog item, must complete so it may be considered potentially shippable for a new, or existing, customer.  It is NOT the acceptance criteria (a common mistake), which is part of a Product Backlog item and defined by the Product Owner.  Rather it is a cross-functional technical checklist of all the activities the Team commits to complete each Sprint and serves as the foundation for the engineering tasks defined in Sprint Planning.  The Product Owner should participate in these conversations since he or she should be aware and understand the Teams’s Definition of Done.  Look to these exercises by Mitch Lacey or Chris Sterling for ideas on how to facilitate this conversation.
3. Hold the first Sprint Planning Meeting – the first Sprint begins with Sprint Planning.  Normally, I schedule about three hours for this meeting and it is HORRIBLY painful.  In my experience, members of the Team do not come prepared to this meeting or know at what level of detail to break down the tasks, so the meeting just is not very effective nor efficient.  This is not a big surprise since the members of the Team or the Product Owner have not done Scrum before and as a result, they do not achieve the purpose of the meeting.  However, since the timebox is the timebox, the Sprint Planning is over.  The end of Sprint Planning signals it is time to get to work since Scrum is about action, not sitting in meetings talking about doing work.  There will be plenty of time to adjust the plan each day at the Daily Scrum.

4. Execute the first Sprint – this step is more-or-less exactly as described.  The Team, Product Owner and ScrumMaster work together to build the first increment of potentially shippable product.  From what I have seen with most Teams, in the first Sprint they almost always commit to more work than is possible, so just past the halfway mark reality sets in and the Team needs to discuss with the Product Owner what scope they are not going to deliver.  In addition, it is a good idea a day or two before the end of the first Sprint to have a short conversation with the Team about the Sprint Review agenda and what they plan to demonstrate at the first Sprint Review.  You would be surprised how often this announcement comes as a shock to some Team members, even though you have explained this part of the process many times before.
   
5. Demonstrate the product at the Sprint Review – the first Sprint closes with the Sprint Review.  This is the first opportunity for the Team and the Product Owner to show the Stakeholders what they accomplished.  While it may not be everything the Team committed to deliver in Sprint Planning, it is important for the ScrumMaster to explain the first increment is a significant achievement for the Team and Product Owner – they have shown that it is possible to deliver something valuable in two weeks (or whatever the Sprint length is).  Use this as an opportunity to get feedback from the Stakeholders about what they would like to see next and if they have any advice for the next Sprint.
6. Facilitate the Retrospective – now this is the chance for the Team, Product Owner and ScrumMaster to inspect-and-adpat and look for improvements.  This first Retrospective is important.  The ScrumMaster should schedule between forty-five and sixty minutes to make sure everyone has the opportunity to share their perspective on how the process is going, what they like about the process, what they do not like and ideas on how to make it better.  The Team must commit to at least one action item in this Retrospective.  To help them be most effective, the ScrumMaster should guide the Team in the direction of something this is attainable and will make a significant impact in their delivery.  Avoid the temptation by Team members to fine tune the Scrum process, i.e. making Sprint Planning more effective, improve the Daily Scrum, etc.  That type of fine tuning will occur day-by-day and valuable Retrospective time should not be spent on something that is mostly trivial.

Now that you have completed your first Sprint, it is on to the second!  Rinse and repeat until the Product Backlog is empty.