Nerdy tidbits from my life as a software engineer

Thursday, June 4, 2009

How I’m Running My First Sprint

The project I’m working on has just started to get serious.  When projects are small, keeping track of your tasks and priorities is easy, because the scope of your project is small and what you need to do is obvious.  But as soon as things get larger and people start to expect certain things from what you’re doing, that ad-hoc approach to software development doesn’t work any more.  That’s when your process really becomes valuable.

Before I came to Microsoft, I worked with a team that did an excellent job executing an agile process.  Our scrums were well-run and it was always clear what our status was.  If we were falling behind, problems and roadblocks were immediately obvious.  What I love about agile is that it frees you from bureaucracy but still chains you to the ground.  You can’t get too far ahead of yourself either by going off on unnecessary tangents, but you also don’t need to burden yourself by demanding that you know everything ahead of time.  It’s both liberating and grounding at the same time.

The product that I’m developing right now is largely unknown, so agile is the perfect process to develop my project with.  And while I might be the only person working on it right now, I don’t anticipate it being that way forever.  So in order to make my process more formal and organized, I decided to hold my own scrums and manage my own sprint – even though there’s only one person involved right now.  I figure that it’s good practice for the future when more people are involved.

So the first steps I took towards running my own scrums were the following:

  1. Enter requirements into TFS
    My requirements engineering process in this case was pretty half-hearted.  Most of my requirements are still very undefined.  I wrote a number of use cases a while ago, which are sitting in a OneNote notebook on my computer.  These helped me make some basic architecture decisions.  But I’m past that stage now.  The requirements, or “Scenarios” as TFS wants to call them, are work items that describe overlying goals.  It’s critical that these get written down somewhere.  Otherwise, the next step has much less meaning.
  2. Put items in a backlog
    Next, I created a list task work items and put them in an iteration path that ended in Backlog.  I tied each work item to a requirement.  This is a very important step.  If a work item did not fall into the domain of a requirement, then I either had to question the wisdom of the work item or add a requirement that I hadn’t defined yet.  The important rule for me is that every work item in my backlog corresponds to a requirement.  This makes sure that I never put work into my queue that is not part of an overlying goal – so I can’t get distracted.  The other benefit of this is that if I open my requirement work item, I can see a list of every work item that is associated with that requirement.  Even better: when I check things into TFS and attach the changeset to work items, I can now follow the chain all the way back to a requirement.  Very cool.
  3. Design a sprint template
    Now here’s where things get strange.  There are of course a number of free templates on the internet that you can draw from, but I found that most of these tailor to specific people’s specific process.  My process is inherently different from other people’s.  For instance, for my money, there’s only a few things that I really care about graphing: the burn down line, and the amount of time left to complete my tasks.  Initial estimates are interesting, but to me they are ultimately only useful from a post-mortem perspective.  They don’t help me from a tracking and planning perspective.

    Velocity is an interesting statistic to track.  But I ultimately don’t care so much about it because I figure that my time-left estimate should take into account my velocity.  For instance, if a task would normally take me half a day to complete, but I’m swamped with some other issue that will delay me by two days, I would expect my time-left on that task to be 2.5 days – not .5 days.  So velocity, as a statistic, should be backed into my time-left numbers.

    My underlying principle for the sprint template was: keep it simple.  Don’t overburden the sprint with too much data.  All I’m really interested in is, am I on track to finishing these work items by the end of the sprint or not?  Other things I don’t care so much about.

    So I started by importing a TFS query into an Excel spreadsheet which automatically populated it with my current sprint work items.  The only columns that I’m interested are: work item ID, title, assigned to and remaining work.  I then filled out a simple table that I fill in every day with my current work estimates.  Lastly, I replaced the “remaining work” values in the TFS table with an Excel function that automatically fills it in with my latest estimates.  That way, when I save the spreadsheet, the work items get updated with my latest estimates.

The end result looks like this:


I anticipate, of course, that I will continue to refine this as time goes on.  But for now, this process is working very well.  As you can see from my chart, I’ve already learned a few important things so far about my current sprint.  First, I have a much higher capacity than I thought I did when I started the sprint.  Second, my initial estimates tend to be more pessimistic than they should be.  I suppose I’m a fast worker.  But without metrics like the chart above, I would never know for sure.  In a few days, depending on where I am, I will know whether I have the time to add more tasks into this sprint or not. 


Anonymous said...

Good luck with the sprints!

I'm currently struggling to move a team of 8 from "Do whatever a developer wants" to some base SCRUM process.

It's been really challenging to get them excited about these tools that are meant to help us develop better software when they can't get over old habits.

Anonymous said...

Good luck with agile - but I think you need to read up a bit more on how you compute velocity and what it's for

Michael J. Braude said...

I struggle with velocity as a concept for running sprints. On some sprints in the past, we've tried to compute this number very precisely during a sprint planning. But I found this not to be worth the effort, because this number of factors into your initial estimates. IE, I could say a certain task would take me .5 days if I didn't have anything else to do; but knowing that I have other stuff going on, I'll estimate it to be 2 days instead.