Scrum thoughts: scrum-of-scrums and daily scrums
Series [ Scrum Thoughts ] Tags [ burndown, confidence, Scrum, scrum-of-scrums ]
After planning, we dive right in to having daily scrums. We’ve gotten these to be pretty efficient (today we had a 10-person scrum finish in around 8 minutes). One key thing is starting on time–we charge people $1 if they are late to the scrum, and no one (not even the scrum master) is exempt. When we get enough saved up, we make a donation to charity (there was a thought that this should go to buy donuts for the team, but that felt a little like rewarding ourselves for being late). Our scrums are mainly a forum for people to schedule ad-hoc meetings with the people they are blocked on (“right after scrum in my office” being the most common meeting that gets scheduled). But running individual scrums is pretty well-documented and understood in the literature, I think.
As I mentioned in my post on sprint planning, we track individual burndowns on a daily basis – how many hours does each person have left against each user story. At our scrum-of-scrums, which happens twice a week, the user story statuses for each team are put together to get an overall sprint status for the product. If you’ll recall, we kept track of the global priorities of the user stories in our pre-planning session, so we can put this together in global priority order.
Then based on the time remaining in the sprint, we can again reassess confidence levels for user stories:
high confidence (green) : requires less than 50% of each person’s remaining time
medium confidence (yellow) : requires less than 80% of each person’s remaining time
low confidence (red) : requires more than 80% of someone’s remaining time (possibly even getting into the “punt” range – someone doesn’t have enough time to finish their part this sprint, because they are overbooked)
The scrum-of-scrums is then a rebalancing effort. If one team falls behind, then you start to see a “striping” effect, where some of their user stories start falling in confidence, even though the surrounding user stories from the other teams stay the same. If you actually color these reports, it becomes pretty visually obvious. The rebalancing is all about trying to swap resources around such that the following principle holds:
No user story should have a lower confidence level than a user story with lower priority.
Ways that we rebalance include swapping tasks from one team to another (this is easier when the teams are vertical striped across architectural levels, as its likely that another team will still be able to do the task in question; however, a similar effect can sometimes be achieved by moving functionality from one architectural level to another (e.g. computing something in the middleware vs. the database)), or by rescoping user stories to make them easier.
Unfortunately, the way we are running sprints now ties the teams down a bit much to always make this flexibility possible. For example, a user story might say “put a Flash widget on the page that does X”, and if we only have one Flash guy, we’re pretty much stuck. If instead the user story said something more like: “we want a user to be able to see or do A,B,C on the page”, then we might have some alternatives if the Flash guy gets overbooked.