Scrum Master Training Review

Scott Schimanski, a friend and colleague of mine, recently attended Scrum Master
training and upon his return, reviewed it for the rest of the team.  With his
permission, I am posting his review here, slightly edited to protect the innocent.

Scott is a former developer and current Project Manager and, as you will see, one
heck of a writer :).  Thank you, Scott, for this contribution and we are all
looking forward to your review of Code Smith.

 

All:

The Scrummaster certification course I took was very worth while. It was put on by
Danube Technologies (http://www.danube.com/).
The trainers were Victor Szalvay (http://danube.com/blog/victorszalvay)
and Tobias Mayer (http://agilethinking.net/blog/). They
were both quite knowledgeable and had lots of experience.

Stories should describe business value

The stories should follow the template: As a <insert type of user>, I want
to add <insert description of new functionality> so that <insert description
of business value>. Our stories on the cards tend to be a little vague and
without business value described. The trainers also had the product owners add business
value to the stories by giving them a dollar amount. For example, the team may estimate
a story at 4 points. The product owner would give the story a business value of $10.
The dollar value is much like story points, they are relative to other stories. We
would divide the business amount by the points and use that value to prioritize
the story. In this example, 10/4 = 2.5 overall story value.

Break stories into tasks

At each planning session, the stories from the stories are listed in prioritized order.
Starting at the top, the team takes a story and starts breaking it into tasks. Each
task is a piece of effort toward completing the story. No task is longer then one
or two days in effort. The team collaborates on creating the tasks. The team will
collaborate with the Product owner to understand the story enough to determine the
tasks. The team may have whiteboard design discussions to help break the stories down. 
We would need bigger boards.

Commitment to stories for the sprint

There are two ways a scrum team takes on stories for a sprint, either by commitment
or velocity. For commitment, the team commits (or accepts for you Dan) to completing
the tasks for a story or a group of stories for the sprint. For each story added to
the sprint backlog, the team voted in a “thumbs up”, “thumbs down” vote whether to
take on that story or not. Disagreements are discussed and brought to consensus within
the team. They would do this for each story until the team agrees on the total stories
it wants to take on for the sprint. Using velocity, the team takes on stories until
they hit their average velocity. The leaders said that commitment is much better then
velocity for putting stories into a sprint.

Self-Managing teams

After listening to what the “team” is expected to do, it seems to me that the team
is not as self-directed as we could be.

1. The team collectively determines the point count for a story. In the training sessions,
   we used a voting method in which 1-5 points were given by each person in a “rock,
   paper, scissors” fashion. If 3 our of 4 people voted “4” and one voted “5”, we would
   ask that person what extra information they had around the story. That person may
   ask the team what information she/he might be missing. The team would collaboratively
   settle on a point count for the story.

2. The team collectively votes on which stories are committed to for the upcoming sprint.
   (see Commitment to stories for the sprint)

3. The team participates in sprint retrospective to help improve the overall agile process.

Defects should be stories

The leaders said that all work should be stories. That included defects and
any clean up work for a project. If work is not in a story, then it should not be
worked on, or as they put it “it does not matter”. For items like “create acceptance
tests” or “create unit tests”, they can either be a separate task or the team can
agree that these basic items are assumed to be part of the every story. The latter
is preferable.

Each sprint should have a retrospective

At the end of each sprint (I consider us currently having a sprint lasting 1 week);
the team should have a quick retrospective. During the retrospective the team considers
what went well and what can be improved in the last sprint. Items to be improved are
put on a “team” backlog. The team is the product owner of this backlog. The team prioritizes
the list of items. The scrum master is tasked with taking the lead to insure the items
are worked on. At each retrospective, the items from the last retrospective are introduced
to see if the team is improving.

Managers should not come to scrum meetings

A person may act differently if their manager is in the meeting. This could have a
negative impact on the teams work at self-management.

Two Burndown charts

This includes Task Burndown charts and Story Burndown charts. The team would track
a burndown chart based on the number of tasks. For example, the first story is 5 pts
and the team breaks it down into 5 tasks. The team then breaks the next story (2 pts)
down into 4 tasks. The team then commits to only those two stories for the sprint.
That is 9 tasks. The team tracks that it committed to 7 points of work. The burndown
starts with the 9 tasks. If at the next scrum meeting the team has completed 3 tasks,
the burndown would reflect 9 tasks on day 0 and 6 tasks on day 1 and so on. Since
each tasks should take no longer then 1-2 days, the team should see the tasks get
“burned” down quickly. The team uses its results from the stories completed at the
end of the sprint for a story burndown. The task burndown is used within the team.
It is not really useful outside the team. The story burndown determines velocity and
is used to show progress outside the team.

Other Thoughts

– The leaders said that the majority of scrum teams are moving away from one month
iterations to two week iterations.

– Everything is timeboxed.  For example, the daily scrum meeting takes no longer
then 15 minutes.  At the end of 15 minutes, quit the meeting.  Planning
sessions, sprint reviews, and retrospectives are all timeboxed similarly.  All
in all, we do pretty well on this.