The team just finished a Sprint with a potentially shippable product.
The Sprint Review is running smoothly, don’t forget this ceremony affects the product only like we wrote here.
The Sprint Retrospective allows the team to find unique areas of improvement without revolutionizing the world-only regarding the mindset and processes in Agile as we wrote here.
But how a Sprint Planning is ending? By having the right stories with defined story points, that will set the next Sprint Goal.
Besides that, the vision of product or service will be present in the stories all the time.
Persons outside of the team (could be users of the system–or people that are helping the team) can bring new bugs that the team needs to take care of–sometimes “quickly”. And this brings delays in achieving Sprint Goal.
Usually, this anti-pattern is happening in Sprint after Sprint and affecting the number of story points per Sprint.
Sometimes the lack of communication with the right person–usually the PO is missing at discussions–brings frustration in the team, especially when the sprint planning ceremony does not happen as the team wanted!
Because later in the ceremony the PO introduces extra features that introduce tests, bugs, changes in the Sprint Goal and these elements will bring overtime for the team or the sense that they are not “good enough” to do their job and other frustrations… and the story points becomes obsolete in these cases!
A simple way to find the causes is to apply the “5 why” technique in the Agile Sprint Planning ceremony.
Causes can be multiple and therefore is important to go through multiple questions and in this way the team will figure out which the cause they are facing. So, let’s start:
The Agile Product Owner change the behavior of some functionalities or they have rewritten some tests, and the team needs to check the incomplete tests made.
Because the increment didn’t meet the definition of done (DoD) that the team has been agreeing on!
Because it cannot do the functional tests inside the Agile Sprint because the team will alter the Agile Sprint Goal and as a consequence the story points.
Lack of Agile PO presence. The team does not know which are the tests that they need to verify!
Because the team is doing their automation tests and do not know if the actual Agile Sprint will include them as delivery at the end of the Agile Sprint.
The Scrum framework helps us to realize the flaws of the organization, but it lets us find the approach that best suits our strengthening context of the organization while having the courage to respect Scrum without changing the rules.
In the Agile Sprint Retrospective event, we can agree on changing the “Definition of Done” and applying the recent one in Agile Sprint Planning.
How can the development team carry out these new tests themselves and arrive at the holy grail of the increment actually “done”?
As always, several options are workable, depending on the context that is unique, but in summary, the question is to find a way for the development team to be cross-functional and autonomous in the execution of tests.
The team can integrate for a limited period the business expert into the development team since he has a critical contribution to get a completed increment.
An alignment with SCRUM framework is happening, which reveals the problems resulting from the operation in silos, here between the IT and the business.
The presence of “business” expertise in the team allows the team to design and execute the relevant tests at just the right moment and accomplish the biggest story points that they engage with. The payoff is obvious for the development team that strengthens their skills, provided that the recent team member accepts the rules of the game and integrates well with the team.
Restrict the work of the development team during the Agile Sprint to the execution or even the automation of the tests, but not to their design. They then do the design of the tests is then before the Sprint, during the refinement of the Product Backlog items, in the presence of the business expert and the Scrum team or at least good representatives.
During Agile Sprint Planning event, the items are thus “ready” – as the test scenarios (acceptance criteria), created in collaboration with the expert, assigned story points and good to work on.
There are still other options to explore, such as the increase in skills (training, mentoring…) of the Agile Product Owner or the Agile development team if it has the appetite (profile of Agile Business Analysts for example), to gain expertise and therefore autonomy without disrupting the Scrum team by adding new people.
You might decrease the duration of the sprints so that corrections from the same non-pass tests can more easily wait for the next Agile sprint instead of disrupting the current Agile sprint that arrives earlier.
This symptomatic remedy does not deal with the root cause of the problem, only tolerating a poor Scrum implementation, allowing the practice of having “testable” but still “undone” increments. It binds you to enter a spiral that will reduce the duration of your sprints until you reach a point where the experts will work daily with the development team – and the option #1 will come into place!
The choice of the most relevant solution depends on the context that you alone control. Applying an agile mindset can help you identify what is more or less easily workable, what you have already done.
You cannot afford in our digitalization world not to be agile and just doing agile.