Since the Clever PM is recovering from a nasty bug, he’s going to rely on Quora for a little Clever content again, this time focusing on the question “How do you get developers to commit to finishing a sprint on time?”  I chose this one because it plays into one of the common misconceptions about Scrum and Agile approaches — that it’s the responsibility of the Product Manager to ensure commitment from the Development teams; this is certainly how it works in the Waterfall world — the Product Manager negotiates a “contract” with the Development team for what they’ll do, how it will be done, and how long it can take.  But in the Agile world, particularly in Scrum, it’s the team that makes the commitment to deliver, based on what they believe they can achieve in their next iteration.  It’s the Product Owner/Manager’s job to ensure that the team has a well-groomed, prioritized backlog to choose that work from.

How do you get developers to commit to finishing a sprint on time?

A sprint is, by definition, a set period of time — usually two weeks.  It starts on day one and ends on day x.  Whatever is done between those two dates is the product of the Sprint.  You don’t extend the sprint, you roll over work.

The primary trick to ensuring that stuff gets done is making sure that thegoals of the sprint are clear, and that the team agrees to achieve that goal during the iteration.  If you have that part down, then getting them to make sure things are done is a matter of social pressure and making sure that the commitments are reasonable.

Scrum (which I presume you’re working under) is a team-based methodology, that relies on the internal pressures and commitments of the team and its members to achieve the goals provided.  When I see “failures” of the team to deliver, it’s often because (1) the work is being dictated to the team, without their say, estimation, or approval; (2) there is no process of confirming consensus within the team as to the goal, and no way of holding people accountable for failures to engage; and (3) there is no form of retrospective to discuss why the goal was not met.

Other than that, it could be that your user stories are too vague, or too big, or not “ready” enough for the teams to engage on.  It could be that your team is too young to fully grok what they’re committing to.  It could be that your team is too old and crotchety to buy into this “Scrum crap.”  It could be any number of things, all of which are going to be very specific to your workplace and your culture.

If you stick to the fundamental principles of the methodology (then adjust for what’s working and what’s not), I think you’ll find that things start to even out:

• Have a clear, prioritized, and estimated backlog of user stories that areready to work.
• Groom that backlog regularly, to find out what needs more detail, what needs to shift in importance, and what needs re-estimation.
• During planning, make sure the teams are goal-oriented and get them excited about delivering something of value that’s potentially shippable.
• Confirm that every member of the team agrees with the team’s commitments before you walk out of the planning meeting.
• Monitor progress on the Scrum board daily, and watch for things that are starting to lag — talk about these things after the daily scrum.
• Review stories when the devs think they’re done, and provide constructive feedback.
• At the end of the sprint, look back and decide what worked, what didn’t, and what could be done better.
• A successful Scrum team is both self-organized and self-motivated — what are you doing to empower the team to make their own decisions and commitments?

In closing, I’m pretty sure if you asked the teams (assuming you have built the trust and respect to do so honestly) they could tell you exactly why they’re “not performing”.