My new recommended “starter” “complementary practice” for new Scrum teams is to simply create tasks and use the “number of tasks remaining” for a burndown. (I also usually recommend that they try to make it such that the vast majority of their tasks are roughly 1 day or less) I encourage them more to focus on PRI (potentially releasable increments), Sprint Goals, and achieving a moderately consistent level of skill at meeting their Sprint forecasts (used to be called “Sprint commitment,” it’s been re-named in the Scrum Guide). I also caution heavily against trying to achieve perfect forecast accuracy as that’s a fool’s errand in complex domains.
Using hours for tasks can lead down some really bad roads, most notably: Former PM’s turned SM’s and other organizational members who try to apply PMI tactics (100% utilization, tracking actuals, etc) tactics to complex software development. By preferring “sticking to the plan” over “responding to change”, they are completely violating Agile and Scrum.
This same bad road can also lead companies into think that “schedule/scope/cost” is an optimum model for software development. As far as I’m concerned, schedule/scope/cost is a dead, failed model for software.
Now, using hours for tasks doesn’t have to lead down those bad roads — but in my experiences, they usually do. Let’s not forget, Scrum used to require hours for task estimation, many years ago, but the Scrum experiences of the wider community over 20 years has spoken on the topic — hours is not always optimum. I would go farther than that and say, at the Sprint task level, it’s usually NOT optimum.
Given the above, I’ll leave it as an exercise to others to describe where using task hours might not lead down those bad roads.
_____
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com
New Courses from ScrumCrazy.com:
- Scrum For Executives
- Agile Requirements: Product Owner and Team Collaboration Techniques
- Scrum Product Owner: Techniques for Success
- Evidence Based Management for Software Organizations(TM)
- Class for Software Development Managers and Executives
If you’re interested in any of our classes, training, or coaching services, feel free to contact us.
Filed under: Agile, Scrum, Scrum Adoption, Scrum Strategies, ScrumMaster Tips, Sprint Backlog, Sprint Planning |
The Scrum Crazy Blog 
I found it can also get very political in that what may take a person 1hr may take another person 4hrs. So it creates insecurities within the team. Then externally facing, business owners (who technically have no say, but do it anyways) want the team to scope down the hours as they’re associating a cost per item based on hourly cost…
I like your suggestion of just keeping it simple and it’s more about burning down the tasks remaining… and the team just needs to focus on working their way down the list together as a team.
Good points Tariq, yet another reason to use this technique.