Tag Archives: commitments

It is a well-documented fact that I love Agile. I blog about it, write books about it, make my kids do their chores in an Agile way… But the realities of an Agile implementation are often full of struggles and angst.

In this blog, we will address the 5 Common Frustrations of Agile teams with some tips on how to avoid.

Great Idea Syndrome or Critical Client Request

These are the ideas that come up, usually from the executive team, that can disrupt a sprint in progress. What can you do?

Have the Product Owner be the ‘interceptor’ and immediately begin flushing out requirements without involving the developers.

Be very transparent with the Executives about the current work in progress and its priority. Sometimes that will diffuse the urgency of the new request.

If it keeps happening, create a Kanban team (or just identify a single developer) that doesn’t have commitments in the current sprint that can take the one-off requests without bothering the dedicated developers.

Commitments aren’t honored

The sprint comes to an end and tickets/tasks/stories just roll to the next sprint. This is often accompanied by loads of excuses but it is demoralizing for the team and devalues the entire Agile process. What can you do?

Work on the definition of done. Does “done” mean tested and ready to deploy? (It should). If so, you might not be leaving enough time for QA so you might have to back up the ‘code complete’ timeline.

Remove distractions and disruptions. If the team is getting hit with new work, then that needs to be removed (see above).

Make sure the team understands and agrees to what ‘commitment’ means. This might start with a working agreement. Often, they aren’t aware that making a commitment means you will get it done. If they think it is okay for a story or task to roll to the next sprint, then something is missing in the interpretation of Agile and its commitments.

Check your estimating. One of the biggest problems associated with missing sprint commitments is the underestimation of how long it will take to finish a story. This is very common with Scrum teams so it is just something you work to continuously improve. Some sprints will be better than others, but taking the time to learn from and refine estimation problems will definitely help in making future commitments.