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 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.
Professional Scrum Trainer
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