Some Good Scrum References

There is a ton of stuff out there on Scrum. About 6,350,000 hits on Google! Our small core team has been scouring this stuff; here are few of the best we've found:

1. http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.html
   

   This is an excellent article which chronicles some real-life Scrum experiences, highly recommended reading.
   

2. http://scrumforteamsystem.com/ProcessGuidance/Scrum/Scrum.html
   

   Nice pictorial overview.
   

3. http://www.scrumalliance.org/
   
4. http://www.mountaingoatsoftware.com/
   

   The last two are just good general sites, containing lots of articles.
   

If you find any other good ones, please share them here.

Getting Down to Scrum…

We had our 3^rd discussion about scrum on Friday, 3/23. The original plan was to try and plan the first scrum about the things we needed to do in order to figure out how to do Scrum. We invited our "Product Owner", Chris to this meeting, and he identified 4 major backlog items. We decided to try and call this 'Sprint' a one day thing and to solve these 4 items – this would give us the first Scrum projects to try around here. We also tried to define a few terms.

A Product is really the outcome or goal of any given sprint. It could be a piece of software, a problem, or whatever. Our definition of this will evolve over time.

Backlog Items

1. Select Initial "Products"
   
2. Declare Product Owners
   
3. Define data needed for Backlog Item
   
4. Define how we will know something is done.
   

Sprint Demo

Our initial products will be:

• Product: Vista and IE7 Compatibility for Advantage Products
  
  • Product Owner: Chris
    
  • Scrum Master: Jason
    
  • Scrum Team (Delaware): Lisa, Allen, Tessa, Eric, Richard
    
• Product: External Checkpoint Failsafe
  
  • Product Owner: Jim K
    
  • Scrum Master: Richard
    
  • Scrum Team (Pennsylvania): Jason, Steve, Jonathan, (Chip – later)
    

Data needed for backlog item:

We will adopt the standards defined in the excellent article Scrum and XML from the Trenches. Teams can feel free to use the term "backlog item" or "story", we will see which one sticks. So our backlog items will contain the following:

1. Unique Identifying Number
   
2. Name - Short word description
   
3. Notes – any additional verbiage to describe the item
   
4. How to demo – a short sentence describing how this item will be shown to be complete
   
5. Importance – a weighted number signifying importance
   
6. Estimate – a guess as to the estimated work effort (FPD's or hours – we can let each scrum team decide for itself).
   

It was also decided that our initial Scrums can use whatever tracking system they see fit. It is up to the Scrum Master. We recommend using simple tools that everyone has and knows, like Excel and notecards.

How will we define "done":

1. A sprint is done when the time allotted is up.
   
2. An item/story is done when it is successfully demoed.
   

Sprint done. Now we're going to roll out the plan to the 2 Scrum teams (Delaware and Penn) today – the goal is to kick off these Sprints on April 1^st – no fooling.

Day Two Of Scrum

We got back together this morning, and had our first "Product Backlog" organization discussion. We had 60 minutes to organize, prioritize, and assign work estimates to our roughly 20 odd "backlog items". And we did it! Here's how. We first took our story cards and put them into Low/Medium/High categories. Then, we went into each category and put the cards in order of what we thought their relative importances were. There was plenty of disagreement, but using a loose 'voting' system we were able to get some order. Here's a snapshot of the board after round one.

The importance rating was next. There was quite a bit of discussion on this, should we use 1 as the most important, what scale etc. I really wanted to be able to build in spaces between the assign priorities so there would be holes for the inevitable new things to slide into. We ended up with assign all LOWS a range between 100-199, MEDIUMS 200-299 and HIGHs 300->. This leaves 0-99 for any really small things (which we don't have right now). We put the numbers beside each story, with a space of ten between each.


The next task was to try and get some time/work level estimates on each story. We ended up using "Fragmented Person Days" as our unit of measurement. These FPDs mean the amount of work you could do on a task given all the other crap you usually have to do. We also added an "A" for All or "S" for single, to signify if we thought the story would require one or multiple people to accomplish. So, for example, if there was an item which we thought would require a 1 hours discussion between 4 people it got assigned "4A". Here's how the board ended up after exactly 60 minutes.

My next step is to setup our "Scrum Dashboard". I got some BIG post-it's with 1 inch graph paper. I'm going to lay that out and post it outside my office to bug everyone!

Last thing to note - the meeting today was actually fun, yes fun. I can't believe it.

Product Backlog

This is our initial product backlog. In our first planning meeting this morning, we will assign weights to these items, and try to figure our a backlog for the 1st sprint.

• Assign Core Team
• Define data needed for a backlog item
• Build reports and charts
• Choose a single tracking system
• Select initial products to roll Scrum out on
• Build process documents
• Design templates for artifacts
• Define a roll out plan
• How will we do retrospectives
• Declare product owners
• How will we facilitate buy-in?
• Define how we will know something is done.
• How can we increase the awareness of corporate products, mission and goals
• We need centralized simple web access to product/scrum/sprint information
• How do our roles map to scrum?
• How to our activities map to scrum activities?
• We need some formal training.
• We need to map current processes & activities to scrum activities
  
• We need to map roles to activities

Day One of Scrum

So, I thought I would cronical our efforts at the "Scrum" thing. Today we had our first meeting with the core-team who is charged with figuring out what Scrum is, what it means to us and how we can use it. The discussions started off right away, and it was very clear that everyone had done some homework. Richard wow-ed us all with awesome big colorful posters with all kinds of scrumy things.

Before we wandered off into endless banter about scrum, I reminded the team about "timeboxing". We only had 60 minutes, and I wanted to end the meeting with at mimimum, the beginning of a "Product Backlog" for our "Product" of figuring out how to do Scrum. We're calling this product "Kaizen".



So we set off on listing out some product stories and tasks. This went really well. See for yourself. Our next task will be Monday morning, when we need to assign relative priorities to these backlog items. This will be the first attempt at a "Sprint Planning Meeting", yikes.