Speedbumps on the Agile Road

I love working on projects that use Agile methods. As a Project Manager, I appreciate the fact that my risk is limited to a Sprint’s worth of work and that I will be showing the customer valuable functionality every 2 or 3 weeks. While I have managed a variety of software and non-software Agile projects, the path to Agile excellence, like in life, has not been always smooth.

Here are some of the more common landslides and washouts I have encountered over the years:
• The team consistently “lowballs” the amount of work that can be done in the Sprint.
It’s time for an intervention!  While you definitely need to have “the talk” and work out – together- how to get your estimates back on track, it always helps to have a few prioritized “stretch goal stories” for a Sprint. That way, should your team members find that they have time on their hands before a Sprint ends- they can begin work on the “stretch goal” stories.

• Team members put in extra hours to make the Sprint deadline.
This one is an absolute no-no for Agile project. When we estimate ( in terms of hours per task) Stories in the Sprint planning meeting , we assume that a team member puts in an “ideal day” at work or 6 +/- working hours (leaving the remainder for meetings, etc).  If Team members consistently put in overtime, the metrics that you are tracking are skewed and no-one will really know what the velocity of the team really is!
If you find that your team members are asking to put in extra hours, it’s a clear indication that during the next Sprint Planning meeting the team needs to be more honest about what they can and cannot accomplish.

• Management begins to compare the velocity of two separate teams – in terms of absolute story points (my boss’s favorite!).
This is a very probable scenario – once your teams are well into their Sprints. Every team uses its own estimates of Story points so comparing absolute story point value of two teams is not really fair. One team’s 8 story points may well be another team’s 3. Instead, encourage management to look at trends: Are all the teams displaying increasing velocity , irrespective of the actual Story point value achieved? If they are, you’re in good shape!

• Unclear acceptance criteria can seriously impact team velocity.
Are your developers complaining that they can’t get acceptance on User stories they think are done?  Look at the acceptance criteria. If your acceptance criteria are not clear at the Sprint planning meeting, make sure that you allocate tasks  for clarifications on each Story as part of the Sprint  and ensure that estimates in hours are made for these tasks.

Sprint Planning meetings go on too long and business owners are complaining.
This is a indicator that you should be limiting “pre-planning meetings” to the Product Owner, Scrum Master, and key developers. At the pre-planning meeting, “groom” the Product backlog and refine prioritization. Identify a Theme and Stories that you think are likely to get into the Sprint. Then use the Sprint Planning meeting with the larger audience of stakeholders  to  finalize the Stories and focus on acceptance criteria and task estimation.

These are a few of the more common pitfalls on the Road to Agile. Of course, one size of Agile can never fit all and it takes several Sprints before the team reaches its peak level of performance. Till then – watch out for these bumps and take early action!

Comments are closed.

About FitForProjects

Based in San Francisco, we specialize in dramatically improving organizational performance by utilizing pragmatic analytics and advanced project management techniques.

Contact Us

Need to contact Us? You can send an email to via LinkedIn or Facebook