Agile Clinic – Scenario One – Not Meeting Sprint Commitment Consistently

An Agile Team is consistently missing on achieving their Sprint commitment for past few Sprints. Even though they have not been able to meet the Sprint commitment and having Spill over, still they have been committing the same capacity. During the discussion with Agile Coach, Scrum Master is not able to justify what might have gone wrong and what the team could have done better.

Let’s try to understand some problem areas

Main Problem Statement - Team consistently missing on the Sprint Commitment

a)       From Retrospectives, no improvement actions are not identified or even if any identified, that is not implemented .

b)      No Root Cause Analysis has been conducted on what might have gone wrong?

c)       If there were blockers/impediments during the Sprint execution, were those visualized to all and taken into resolution?

d)      Was the team ready enough before committing on the Stories during Sprint Planning?

e)      Did team consider the adhoc item capacity while planning for Sprint?

f)        Were team members very clear on Acceptance Criteria and Definition of Done

g)       Was the Product Owner notified/informed about the Sprint Progress

 Understanding the problem statements above, lets now discuss on some of the good practices (Pure Scrum and Scrum AND) and people may differ always.

Practice 1 – Transparency on the Sprint Progress, Inspect and Adapt as necessary

Transparency, Inspection and Adaptation are three Key Pillar of Scrum Success. While executing the Sprint Dev Team should keep things visible and transparent to the Scrum team and stakeholders. As per Scrum Guide, even after Sprint commitment, the Product Owner can help to clarify the selected Product Backlog items and make trade-offs. During the Sprint execution, if the Development Team determines it has too much or too little work, or there are blockers/impediments blocking the progress of the Sprint, it may renegotiate the selected Product Backlog items with the Product Owner.

             It is extremely crucial to keep the Scrum/KANBAN board updated. As per Scrum Guide, The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.

              So, as Scrum Master, we should encourage team to highlight the challenges and check with Product Owner all the team on probability of the meeting the Sprint Goal and adjust as necessary.

Practice 2 – Effective Retrospective

Purpose of Retrospective is to get better. The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

             When the team is not able to meet the Sprint commitment consistently, question automatically comes into picture, have they conducted the Sprint Retrospective and taken care of the action items to get better? It has been observed and considered as major anti-pattern in most of the Scrum Teams that retrospective just becomes a ritual and not carried out the way it should be.

Some anti-patterns

• Retrospectives become a template – same findings always
• Historical data than focusing specifically on the last Sprint
• Blame Game
• Action Items are never created
• Progress on previous action items are never tracked
• Actions items are created just for the sake of creating, however no buy in from Product Owner to get those (as per Scrum Guide at least 1-2 major items can be considered for next Sprint) implemented in the next Sprint

As per Scrum guide, By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself.

Sometimes it is good to conduct a problem solving workshop after the Retrospective to identify the root cause of the problem so that the corrective (and preventive measures) measures can be taken. Root Cause Analysis provides a set of problem-solving tools used to identify the actual causes of a problem, rather than just addressing the symptoms

Practice 3 – Readiness before Starting a Sprint

Before Staring a Sprint, it is always recommended that team take part in the backlog refinement (Max 10% time for some team members) along with Product Owner (Or Proxy Product Owner) to ensure they have adequate information/knowledge to commit the Sprint Goal. Some most important things to consider (not exhaustive though)

1.       Prioritization from Product Owner

2.       Just Enough Knowledge/Information on the Product Backlog Items

3.       Capacity of the Team

4.       Understanding the dependencies/risks beforehand (dependencies could be with upstream /downstream application, could be on data, could be on other teams in the same train, could be on other trains and many more)

Practice 4 – Clarity on Acceptance Criteria and Definition of Done

During the Backlog refinement team should have discussion with Product Owner on finalizing the acceptance criteria for the Product Backlog Items. Many teams face difficulties in understanding the difference between the Acceptance Criteria and Definition of Done.

Most of the agile team usages user stories as the way to discover requirements (even though User Story is different from requirements), the user story is known as a reminder to have discussions at the right time. When they discuss the user story, they identify things needed to make that user story meet the condition of satisfaction of the business user. Development team understands the user stories by understanding these conditions of satisfactions which are called Acceptance criteria. If we go by Ron Jeffries 3C Model of User Story, the third ‘C’ i.e. Confirmation relates to the Acceptance Criteria and is mostly given by Product Owners.

             But can we get a ‘Done’ from Product Owner after meeting just the ‘Acceptance Criteria’ for the Story? Answer is ‘No’. Dev team should meet the ‘Definition of Done’ to confirm the completeness of the Story and then PO can mark the story as ‘Done’.

Definition of Done, has agreed upon set of things which each product backlog item must comply with before it is considered complete. Following are Sample ‘Definition’ of Done for one team

1.       All Acceptance Criteria for the PBI must pass

2.       Sign-off for the PBI must happen in a clean environment

3.       Seventy percent of the test for the PBI must be Automated

4.       There must be no Severity 1 or 2 defects for the PBI being signed off on

5.       The unit test code coverage must be at 80 percent

Mostly this is created by Development Team but should be in alignment with other Scrum Team Members as they clearly understand what it takes for a Product Increment to be ready for release.

To summarize, the Definition of Done

·       Creates a shared understanding of what is releasable software and

·       Guides the Development Team in the Sprint Planning on how many PBIs it can pick from the Product Backlog as their commitment

Simply put, the difference between these two is that the DoD is common for all the User Stories whereas the Acceptance Criteria is applicable to specific User Story. Acceptance Criteria of each User Story will be different based on the requirements of that User Story.

In order to comply with commitment reliability, it is extremely important to have clarity on “Acceptance Criteria” of all PBIs and “Definition of Done” as a whole. Also, it is very important to make the ‘Definition of Done’ more Stringent as the team gets more mature.

Practice 5 – Understanding the Priority from Customer – Capacity Based Planning

Development teams will get the priority from the Product Owner for ‘pulling’ the PBIs from Product Backlog into Sprint Backlog. Now, this prioritization may vary depending on the nature of engagement and the type of work they are supporting

• All Planned and prioritized items before starting the Sprint – ideal scenario
• No Planned and prioritized items – request will always come on adhoc basis and Just In Time
• Majority of the items are prioritized, however there may be some adhoc items coming during the Sprint execution
• Team has clear segregation of capacity (new enhancements, defects and technical debts, enablers and NFRs)

From the rule of empiricism and by inspecting the previous Sprints, dev team should be understanding the pattern of the priority from Product Owner so that they can adapt to the situation and commitment vs accomplishment anomaly can be reduced.

Practice 6 – Understanding Team Capacity and Refine it as appropriate

Understanding team capacity is very crucial for meeting the Sprint Goal, where over committing and underachieving is not desired, similarly consistently under committing and then overachieving is also not acceptable. Team should again apply inspect and adapt of the Sprint Goal Vs Accomplishment pattern for the past Sprints and self-organize themselves before committing for the upcoming Sprint. Again, it is never recommended to come to any conclusion just by seeing one Sprint outcome rather it is always recommended to check the pattern for couple of Sprint before refining the approach.

Thank you for reading through this article. Feel free to share your comments. There is always opportunity to learn from others. Wisdom of the crowd is priceless.

Subhabrata Pal (Subho) - Enterprise Agile Coach

[email protected] - +919830619877

References

Scrum Guide (scrum.org)

Hiren Doshi Book

Images from Google