Udostępnij za pośrednictwem

Sprint 6 winding down

  • Artykuł

Well, we finally kicked off sprint 6 in June, and it finishes up next week.  Being summer, there have been a lot of vacations plus a Microsoft-wide forum that ate up a lot of time.  I expect that sprint 7 will have fewer randomizations, esp. since the core Whidbey work that the other part of our team is working on is winding down.  However, for several reasons we will still be a bit short on people during sprint 7, so we probably won't start any kind of dual-sprint approach until sprint 8 (which would presumably start in mid/late August).

During this sprint the team has spent a lot of time talking about improving estimates, and tracking the time spent.  Some people suggest that we track the time spent on each item, but of course some (myself included) think that's a bad and non-agile road to go down.  My personal view is that the things that slow us down tend not to be massive underestimation of work items (although we're far from perfect in that regard), but rather getting hit by other things.  We've tried to account for that in sprint 6 using a "risk reserve" as I've alluded to in prior postings.  That has worked fairly well in terms of setting aside sufficient time to deal with randomizations, although it's hard to get people to account for overhead and materialized risks.

Another issue that keeps coming up is that we keep saying we'll deploy our stuff every other week or so, but invariably it gets pushed to the end, which of course increases pressure in the last week.  Hopefully we can find a way out of this in future sprints.

I continue to see positive communication and team cohesion results from Scrum, which alone make me want to continue using it.  In addition I feel it's a great way of organizing work and getting shared focus on a set of goals.

The really interesting stuff will happen with sprint 8 when we try to do "mainline" product work using Scrum...

Over & out!

Chris

Comments