“They always say time changes things, but you actually have to change them yourself.”
― Andy Warhol, The Philosophy of Andy Warhol
Burndown at the end of a sprint is indicative to a team’s velocity. This equates to the amount of work a team can squeeze out of a single sprint. After a couple of sprints, as a team gains domain experience and knowledge, velocity is expected to improve. With this in mind, how does one go about answering these quinella?
- When is the release date?
- How much is this costing us?
This blog post aims to answer the above questions, and provide a SCRUM spreadsheet as a tool we use for commitment-drive SCRUM.
The real-world lo-down
Let’s take a step back. If you do SCRUM properly, the question of release dates is moot. That is having a potentially releasable product, which can be pushed out to the world at moments notice, is a utopian scenario for any product managers. This is achievable only through hard yakka and paying down the technical debt, one -ilities at a time.
Externals in the SCRUM team? By adding billable consultants to the team one may start to wonder how much is any of this costing us and is this going to eat into our slush fund?!
Further complicating the overall picture, in the real world, engineers are usually not confined to a single role, task, or team. Some of us do presales, training, support, consulting and generally split our working efforts in various activities (even blogging!). The annoying thing with velocity is that, these “other” activities that are not part of the sprint backlog are categorised as interruptions and/or blockers. These interruptions ultimately impact the team’s velocity. Traditionally if you are a product development team, your central role is to build features, fix reported bugs, and push out releases. Not presale, not training, not support and not consulting.
Support is indeed tricky. Typically one is unable to estimate how much support may flood in. This is at loggerheads with the notation of an agreed sprint backlog. Though this can be mitigated with lean principles, WIP and cumulative burndown, but that is not SCRUM and the discussion is for another blog post, another time.
User story points vs man hours
If you come from the SCRUM school of Mike Cohn, like me, you should already be tut-tutting, arms crossed and ranting, “one should not measure velocity in man hours but in user story points!” However if you have a steering group asking for the release dates and cost of development, or you have external consultants billing hours on the project, you know the only measurement that really matters is man hours, which can be directly translated into a monetary cost.
Using man hours is a double edged sword. The clear benefit is that you are immediately given a sense of expected delivery. This contradicts the central premise of user story points, that a task should be measured on its complexity and size based on a common understanding and analysis. At this point we are unsure if time-based estimates are better suited for us than user story points.
The other issue with time-based estimation is that team members may find themselves giving dishonest estimates, be it too optimistic or pessimistic. Be weary of people touting “oh they build xyz in just one day.” Or, “it’ll take me 10 years to do xyz”. Both quotes should trigger alarm bells.
Commitment-drive
Most engineers are used to percentages as an indicator of commitment. For example, “I’d spend 50% on project A, 20% on project B, 10% on meetings and doing expense reports, and 20% on water cooler conversations this week.” is not unheard of. This simple model fits our sprint schedule, where one could identify their non-working days ahead of time, percentage of working hours for each projects and tasks, and a preliminary prediction on admin and meeting hours.
Naturally none of the existing SCRUM tools of the world currently support the notion of commitment. Therefore as part of evaluating our tools and processes, old school spreadsheet was deemed worthy of a revisit. I have come across some of the most comprehensive SCRUM support and prediction models that was entirely written in Excel. So I was not too surprised that we stumbled on this stirling little pearler of a SCRUM spreadsheet, by Xavie Esteve. The spreadsheet has a great burndown chart and uses estimation in hours. It is simple to get started and we loved it. I extended it with calculations based on commitment, helping to determine if we have fit the right amount of tasks based on the predicted maximum velocity. The end result is here and the following were added.
- Theoretical maximum team velocity
- Reduced max team velocity based on planned engagements
- Adjusted max team velocity based on adjusted capacity based on unplanned engagements
- Recommended daily burndown per person
All calculations above take into account vacation days, public holidays or any other planned non-working days.
The biggest benefit is that we used commitment to incorporate other tasks in our estimation and sprint planning. For example, individuals on weekly support are capped at max 50% commitment to the team.
Shortcomings
The spreadsheet is an excellent starting point. But it really lacks the overall picture. The following would be fantastic to have.
- Task assignment and notification
- A sprint board
- Re-adjusted daily burndown prediction based on unplanned non-working days or engagements
- Calculating expected velocity based on previous sprints, perhaps based on an average or median
As a side note, we are still evaluating other options and tools. Stay tuned.
something else 