Scrum (Part 1: Planning & Poker)

One of the things I have really enjoyed here at Sony is working within a Scrum.  I plan on covering this topic in three separate posts.

1. Sprint Planning Meeting
2. Daily Scrum
3. Pros/Cons

Lets start with the basics... What is a Scrum? As Wikipedia says:

Scrum is an iterative, incremental framework for project management and agile software development.

That seems a bit wordy.  I typically read at a 5th grader's reading level, so from my perspective: its a process for breaking up a large project into manageable bites.  In Sony's case, 2 week 'sprints'.

At the beginning of each sprint we hold a Sprint Planning Meeting, which is the official title for figuring out what the hell we need to do in the next two weeks to meet our deadline.  This meeting usually starts by prioritizing the list of 'stories' we need to complete and estimate how long each one should take.  A story could be 'I would like to able to log in and out of the game.'

We (anyone involved in this story) then estimate how long this story will take to complete by using Planning Poker.  Planning Poker involves giving each person a deck of cards with numbers on them representing days of work.  Each deck has cards with numbers (1,2,3,5,8,13,20,40,100,?).  Each person decides how many days he/she thinks the task will take, finds the appropriate card (rounding up), and then at the same time everyone flips over their cards.  So if you think a task will take 6 days, then you will find the 8 card and flip it over.  If everyone agrees, great, move on to the next story.  Otherwise, the people with the highest and lowest estimates plead their cases on why they think it should take as long as they estimated and then everyone gets a chance to pick a new card and flip again... this process continues until there is a compromise/majority.  Once a good chunk of stories have been estimated we look at how many days of production we have available for this sprint and figure out how many stories we can tackle.  This entire process of choosing and estimating stories usually takes most of our morning.

In the afternoon we meet with our teams (in my case, the client team or Flash team) and we break down each story into tasks.  A task might be 'Create a modal for when you get disconnected from the server."  For each task we then estimate how many hours we think it will take, using a similar process as above although we are usually less formal at this point.  We give ourselves 6 hours of work each day to buffer for everything that comes up during a normal day as well as to help counter underestimating on tasks.  Tasking out all of the stories for the two weeks usually takes the remainder of the day.

Thus, we just spent 10% of our two week sprint in initial planning alone.  From here, we jump into our work while monitoring our daily progress.  I will explain in more detail in a future post.