Select Page

Universal Customer Care is a platform and service provider in the area of Customer Relationship Management. Their upcoming release of their software platform involves four different scrum teams working on four different components with co-ordination at a release level being facilitated by a Release Manager. The software releases happen every quarter. The release manager co-ordinates a release planning session working with the business and the scrum teams at the end of which teams make a broad commitment for a set of features (broken down into epics and stories). Teams work in 2-week sprints (6 sprints for a typical release followed by a week of hardening) with the release manager coordinating release commitments and dependency management through a scrum of scrum mechanism. There is a management review every month involving the Delivery Head for the platform team, Product Manager for the software platform, Release Manager and the Scrum Masters of the four different teams. The organization has been using Scrum for several years now and teams are fairly mature collaborating well with product management and operating in a self-organized manner.

At the end of month 1 for the current release, Warriors and Dolphins, two of the four teams working on the release are somewhat behind on their commitments meeting only 50% of the committed stories in sprint 1 and 70% of the committed stories in sprint 2, while the other two teams are on track.  Given that it is only a 3-month release, there is perhaps a significant risk involved in not delivering on overall commitments for the program.

What would be your recommendation in terms of how the management should approach their first monthly review? What follow-up actions do you foresee?

Suggested Solution / approach

It is definitely a concern that two teams are at 50% of their commitments by month 1 – if the trend continues (assuming the other two teams continue making their commitments), half the commitments made by two of the four teams would not be met – which essentially means 25% of the overall commitments on the project not met.

However, the following questions are relevant and should be asked by the teams themselves first. What is the probability of them increasing their do/say ratio over the next four sprints? Are they in a learning mode? Are there newcomers causing a slow-down? Are the teams doing enough “swarming” to complete stories that are started before taking up other stories? What is the remaining effort for completing committed stories from the first two sprints (is that also 50% of the overall effort or is it substantially less)? Are there other soft factors (those we talk about as being below the iceberg) causing a slow-down? Are these questions coming up in the teams’ own retrospectives with actions identified by them to fix whatever they believe are the issues? In fact the first question as part of Program Governance for these two teams should be about what their individual team retrospectives reveal and what the recommended actions are.

If the Program management / Governance is convinced that the two teams can not make up enough then one needs to look at more even distribution of load – may be check whether the other two teams can take up some more responsibility and deliver. Here again, the retros from the other two teams would give a great idea – for example, are they challenged enough? Are the Scrum Masters of the four teams sharing learnings and working on helping each other balance their load? The idea should be for the Program Governance to encourage and facilitate problem solving at the local level first before they get in with their recommendations and actions.