My previous blog was about what to expect from the first Sprint in Distributed Agile. As we all know, for every open-ended question there are at least two possible answers – theoretical and practical. With the popularity of Distributed Agile in our industry, we quite often react swiftly in answering the question ‘When do you say that your Distributed Scrum team is successful in a Sprint?’ And in all such swift instances our answers comply with the theory. The theoretical answer is very straight forward – ‘When all user stories committed at the beginning of an iteration are completed according to the definition of done (DOD), we can say that the team is successful‘. This answer comes from the need for action orientation and commitment.
Recently, as I delved further by discussing this question with my fellow professionals, I got to derive a practical answer. This answer looks seemingly inclusive as it considers the following factors:
Meeting Delivery Expectations: Delivering all committed user stories according to DOD is one among the many key factors. Depending on the project context, it is reasonable to agree on the percentage of user stories to be completed. Rarely do we come across any project team that completes all user stories at the end of all Sprints. In one of my agile development projects, I considered 90% completion as the measure of success during the first 5 Sprints and 95% completion during the rest of the Sprints. With the assumption that all user stories get prioritized in order to deliver business value, this approach of measuring success works in practice when we consider the other two factors discussed further in this blog.
Team Satisfaction: At the end of the Sprint, it is very important that the team moves forward with a sense of accomplishment and satisfaction. This is necessary to sustain team motivation. Also, virtual teams that nurture rapport and build trust feel happy to communicate and coordinate regularly. Needless to say, happy teams deliver better results. Measuring the number of user stories completed at the end of a Sprint makes sense as long as the team is happy and feels motivated.
Continuous Improvement: It is not enough if user stories are done and the team is happy and motivated. The team must have carried out effective ‘review and retrospection’ on both project management practices and engineering practices. This is one way to identify and reduce technical debt so that the team can have a better Sprint the next time. This will also help the team to move forward in a sustainable pace to deliver business value.
Considering the above discussed factors, our approach towards measuring success would need to consider:
There certainly are many challenges in balancing these three factors while executing projects.