Scrutiny and scheduling

Well, yesterday after much time spent learning the subtleties of Excel’s SUMIF formula and the difference between B7 and $B$7, I was able to add a handy new feature to our daily scrum spreadsheet: the ability to sum up the work remaining by person.  I added a graph too.

 

I know, I know, it doesn’t sound like much, but it’s very useful.  Often during daily scrums we would ask questions like “how many days of work does Dan have left?” and I would have to start selecting ranges and looking at the sum in the status bar (a highly useful but hard-to-discover feature).  This way, it’s all right there.

 

The dark side of this is that a manager (or ScrumMaster) who is not vigilant about keeping an agile mindset and team-oriented environment could use this per-individual data as a whip to try to force progress.  But that would be a misguided use of this data: the data in a scrum burndown is strictly the scheduled work for that sprint, and doesn’t include OOF’s or other work that’s totally unrelated to the sprint.  (What things to include on the backlog and what things to track in other ways is another discussion.)

 

One issue that keeps coming up is that unforeseen distractions often cause people to tick off less than 1.0 days of work each actual day – more so than error in their work estimates.  So we keep trying to make note of these things and in most cases take note of them as “overhead” that is factored in during planning for the next sprint.

 

The encouraging this about all of this is that our estimates are now, in my opinion, much better thought-out and realistic than the estimates we used to produce.  This is somewhat ironic – Scrum bills itself as something that tries to limit up-front planning, and yet we are finding it able to produce better overall estimates than what we were doing before!

 

Over and out…

Chris