Our team's sprint cycle typically ends every 2nd Wednesday morning after two weeks. It is two weeks of grafting hard to finish the work allocated during Sprint Planning.

In all honesty I have always dreaded this day. At that point you already know why things failed and the reasons preventing you from finishing a story. (Clue: These are mostly self-inflicted). Then the disappointment when you know you have to carry over work into the next sprint. I hate carrying work over because I feel I'm living in the past again.

The beauty of having Sprints is that it gives the work you do immediate purpose to work you have to finish within the sprint cycle. It adds a dash of pressure which I believe is a good thing to have. So understandably when I do not finish all my work I feel like I failed.

Clearly, we were doing something wrong! Through continuous evaluation and reflection we identified three areas of improvement which increased our productivity dramatically.

As a team we identified that our stories were too large

Story points are relative. There is no standard metric. Looking at past sprints using JIRA we identified 8 story points in our team would typically take 2 weeks that is if there are more than one developer working on the item. We identified that this was the number we had problems with the most. After many unsuccessful attempts we started splitting stories of 8 points into two or three parts. Having smaller stories made a huge difference. There is a small catch. A story should be demonstrable. It's not always possible but should be a rule of thumb. We slowly increased our velocity by closing more and more stories because we narrowed the focus by making them smaller. It was not the silver bullet but it did give us momentum and instilled more confidence gradually as we finished more and more stories in the allocated time. It was setting us up for success but also being realistic.

A lack of understanding your external dependencies can ruin any sprint severely

The project feature we were building was of such nature that it required many cross department service integrations and data. For example, an ETL process required services from four different teams. Our application feature is hosted inside our department's main application which other teams are responsible for. The sum of all these parts (external dependencies) made our project. This was certainly a first for me and I have done my fair share of projects over the years.

The reality was that we required time to up-skill using these services and work on the relationships to effectively collaborate with these teams. This made it complicated as these individuals had other time constraints and deadlines as did we. There were constant delays in communications in trying to understand the implementations or trying to source documentation. This is completely understandable.

However, it did become a major problem for our team. We planned stories where we needed to source information and work on external services integrations but almost every time it had to carry over into a next sprint because we not well informed and we struggled. Mostly we had to schedule time with someone for guidance or clarification. Glad to say willingness to help was never an issue just finding time!

As our definition of ready we added two questions during Sprint Planning and Tasking:

• Is there an external service or integration point for this particular story?

• Is there an external person we need to speak too?

It could be both or only one of these at a time but in our experience either of these can be time consuming and easily delay delivery of stories.

When we were planning and we could not answer these questions we would add a Spike to investigate and gather sufficient information on the usage of a service or we had to schedule time to speak to the product owner or subject matter expert. The conclusion of a Spike should always attempt to produce a Story (action item). Our sprint became more burdened with spikes but in the long run our stories of this nature had more success and we were able to finish more before the end of sprint. Our stories were more informed and tasks were better refined and therefore easier to do because we were proactive in removing complexity upfront.

Sprint Planning 2 should be fun, engaging and is the first step towards breaking down silos in the team

Do you do tasking/Sprint Planning 2? Typically Sprint Planning 2 (SP2) is where a team approaches the story in a technical manner breaking down the story into practical tasks. Typically product owners/people aren't involved. They have contributed managing the backlog and producing the stories we have to work on as decided by the product and stakeholders.

An simple example of tasking a story

Story: Adding 3rd Address field to database.

• Task 1: Create script to add field into database using Flyway Migrate
• Task 2: Add the field to the data transfer object (DTO) in Api code
• Task 3: Map the DTO to the model in code (Repository pattern)
• Task 4: Dev Test
• Task 5: Add Unit test
• Task 5: Deploy to managed environment
• Task 6: QA test and sign-off in managed environment

In the past we had tasks

• Code
• Test
• Deploy

Not specific at all. What must one code?

Note: that this story is demonstrable by showing the new field in the API response.

Our team was distributed between Ukraine, United States and South Africa therefore we decided to have SP1 and SP2 on the same day. The initial idea was to have all the planning at once so we spare a couple of hours for coding and testing. We started 14h00 or 15h00 during daylight savings in the afternoon as the US just started the work day. SP1 usually enjoys most of our left-over energy and there are few issues and remember we also have worked on these items previously in backlog refinement/grooming session(s). It really helps to have a Product Owner who is organised and not uber technical. POs tend to untangle techies when they get stuck in the weeds!

By SP2 the fatigue and decline in motivation usually crept in. To be fair it has been a long two weeks and now end of day. Our initial approach was a team member would open a JIRA board on Microsoft Teams and we would mention tasks to the stories to try and break these down further while one was typing in JIRA. We could also argue that SP2 was not valued as super important. Our approach was boring and I always felt we just got on with it to get it over and done with. One person was active and the rest where bystanders and watchers. This resulted in many missing tasks and unclear information due to bad planning and bad discipline.

I came up with the idea where instead of using JIRA lets use MIRO board (I'm taking credit for this one - forgive me). Miro board allows multiple connections enabling users to collaborate at the same time, real time in a wide open virtual space. Additionally, Miro allows one to import JIRA stories. So we would typically import the stories and there definitions. Once all the stories were on the screen everyone would start adding tasks underneath the stories at the same visible to everyone. We would do this in silence for about 20 minutes. After the allocated time every team member takes one or two stories they know the least of and start presenting the tasks and have the team discuss them thoroughly until everyone is comfortable in their understanding again taking into account the questions on who we need to speak to and what services we need to integrate with.

Once everyone is done presenting their items every member would add these tasks to JIRA and the sprint would officially start. These discussions is a step towards breaking down silos in the long run because every story and every task get discussed to ensure that everyone understands the purpose. I even prefer having these on Webex or Teams rather than white boarding in the same room. It puts one less on the spot and is more efficient time wise in my experience. Engineers are more comfortable at their PCs. It can also be recorded!. It is up to every team what they feel comfortable with.

What that did for the team was huge.

• Everyone is involved and actively contributing. Everyone is more engaged and alert. I feel that contributes to more positive and complete solutions. A group decision is better than one persons decision I feel.

• Presenting a unknown story and its tasks give the presenter the opportunity to understand the story and what is required. Explaining to others always helps improve understanding of the story and its tasks.

• Our completion of stories were more efficient and we had very little unknowns we had to deal with. We put the team in more control of what we could control.

It is worth noting that we decided to have SP1 and SP2 on different days. SP1 we do after our retrospective on the last day and because of grooming refinement we usually do not have a lot to figure out. We just need to prioritize and make sure we did not miss any important information. SP2 can now be completed with a fresh perspective and there were sometime to think about the stories planned in SP1.

We now have more control over the unknowns and more control over the success of our sprints. We also make the morning of sprint end for learning and personal retrospectives. We avoid working on anything even if we couldn't finish some of the previous stories. That still happens but a lot less.

Conclusion

The last day of the sprint has become a day everyone looks forward too. We do not rush towards the end anymore to get work finished. We decided to treat the first day of the sprint as we would have in the past approach the last day. We start fast and ease up towards the end. In the past it use to be relaxing the first day and sprint towards the end. The last day has become a reward for our efforts for the past two weeks. Some members up-skill in new tech while others improve their understanding of the business. There is freedom to decide. A little me time at work!

I'm fortunate to have worked in a team where honesty was paramount even during times we know we are doing something(s) wrong and we needed to change our approach. Together we did enforce change and after making many mistakes we constantly improved, reviewed and reflected and found ways within the Agile methodology and our scrum approach that worked for us and contributing to our confidence and success.

We are more dependent on Agile than ever before!