Agile methodology stresses continual change and evolution within the Scrum framework. In my last post, I provided some ideas to spruce up sprint ceremonies and encouraged the reader to look for additional opportunities to enhance their sprint activities. That said, I relish the role of devil’s advocate, so I wanted to share about an area where I think change can hurt, not help, teams.
During part 2 of Sprint Planning, the Scrum team takes the user stories the Product Owner has proposed and deconstructs them into tasks, to which they traditionally assign hours. Assigning hours to tasks is one of those traditional project management burdens that many Agile teams regularly try to get rid of, and I’ve noticed teams recently moving away from it.
There are plenty of reasons to abandon hours (they’re too granular, they get away from the essence of effort pointing, it’s an unnecessary use of time, my team doesn’t like it, etc.), and I’m not going to debate the validity of those concerns, but I’d like to argue that the value outweighs the pain.
Is That a Roadblock I See?
When teams are assigning hours to tasks, it allows everyone (particularly the Scrum Master and developer on the task) to see when a roadblock is on the horizon. If a team member assigns two hours to a task and is still spinning his wheels on it two days later, that is a pretty obvious indication that something has gone wrong. Either the work was severely underestimated, the team member isn’t focusing on the Minimum Viable Product or a roadblock is hindering progress. In any case, this gives the SM an opportunity to step in and help overcome the challenge at hand.
Without hours estimated by the team, it is far more difficult to know when to step in, and Scrum Masters are always looking for cues to most effectively support our teams.
The Gut Check
Healthy, well-established teams should have a handle on their average velocity so they can accurately pull the right number of stories into each sprint. However, assigning hours to tasks allows for a good gut check to confirm the team has pulled an appropriate amount of work into the sprint. Most agile software tools allow you to set a capacity for your team (hours of work per day/team member, type of work, days in a sprint, etc.) so you can see when you’re blatantly off course.
There will be scenarios where the hours don’t end up being accurate due to missing information or roadblocks, but that holds true for effort points as well, and if we can’t agree that velocity is important, what are we doing here? It’s also worth noting that there shouldn’t be an expectation of the hours tasked matching the hours available down to the minute. Like I said, this is a gut check, so we’re just trying to ensure the hours designated don’t significantly fall above or below the sprint capacity.
A Well-Balanced Sprint
When teams effort point they do so collectively – regardless of job description – which means that effort alone cannot readily tell a team whether they have a balanced amount of work for various skill sets of the team. As noted above, assigning hours to tasks allows teams to review their capacity, which in turn provides an indication of whether any team members will be light on work. So if, for example, your front-end developers determine they’ll be light on work out of the gate (which they would readily see based on hours assigned to tasks), they can turn their attention to adding value to the project as dictated by the team and client. They can sneak in additional user testing or assist with Quality Assurance efforts. This way, they’re still adding value and being fully utilized.
But Isn’t That Just… Un-Agile?
It can be difficult for many Scrum teams to reconcile the iterative, team-based nature of Agile with the tediousness of time tracking. And believe me, I get it. Hours seem like the ghosts of our waterfall legacy, doomed to haunt our projects forever.
In the past, yes: hours were rigid documentation that locked us into delivering only specific items based on a pre-determined contract with our clients. Basically, hours were the embodiment of everything the Agile Manifesto rejects. But within Agile, hours become milestones by which we can self-assess and correct the course during development. They’re more specific than effort points, and more relatable to your Product Owner.
When used correctly, hours are a blessing, not a burden; all that’s required is a fresh perspective.