Share via

Our Scrum Cycle

  • Article

I've mentioned in a previous post about how our team has adopted Scrum and agile methodology... at least in spirit.  :)

I thought I'd share some of the specifics about how we're running it.  This is primarily based on direction from our Engineering Manager, Mark Mydland.  He's brought Scrum and agile to other teams, both in and out of Microsoft.

At first, our sprint duration was 4 weeks.  This is a very drastic change to typical Microsoft engineering.  We usually break up work into 3 month milestones.  Our iteration duration has but cut into a third!

Recently we increased it to 5 weeks based on feedback from others in our product unit.  I'm not as pleased with the 5 week duration because it increased our development time by 50%.  I'll explain the details later.

We start with a week of design.  We meet in the afternoon for 4-5 hours.  Each developer gets to pick up a design area.  In the morning or in days before their target design day, they are responsible for preparing their design discussion and collaborating with a QA owner.  Long gone are the 15 page development and testing specs.  We use a unified design doc for both dev and test.  The questions asked in the design doc include:

  1. What is my general solution to the problem
  2. What other alternatives are there?
  3. What is the general pattern?
  4. List of dev tasks
  5. What is it I'm trying to test?
  6. What is my general approach for testing?
  7. What will customers do with this feature?
  8. List of test tasks

By the end of design week, engineers enter their tasks into TFS and link them to a Deliverable (a custom work item type used to group up tasks related to a specific feature).  I review the TFS tasks and sign off on each deliverable.  Each deliverable has a rank value that indicates the order in which we'll address each feature.

Weeks 2, 3, and 4 are primary implementation weeks.  I'll go into how I manage the work during those weeks in more detail in a future blog.

The final week is about stabilization.  Some feature work may continue but the focus is on finishing up remaining work, evaluating overall application testing, and getting the application polished.  In the developer division we also have things called Quality Gates which include things like making sure you are FxCop clean and that your binaries have 70% code coverage from automation.  We'll make sure all those Quality Gates are met in the last week as well.

Clearly our Scrum cycle is unique.  I'm curious how others do Scrum.  I've read a few books, but I'd like to know how others do it in practice.  What do you like?  What would you like to improve?  Any suggestions for me?

Comments