services
A holistic approach that accelerates your current vision while also making you future-proof. We help you face the future fluidically.
Digital Engineering

Value-driven and technology savvy. We future-proof your business.

Intelligent Enterprise
Helping you master your critical business applications, empowering your business to thrive.
Experience and Design
Harness the power of design to drive a whole new level of success.
Events and Webinars
Our Event Series
Featured Event
22 - 24 Jan
Booth #SA31 | ExCel, London
Our Latest Talk
By Kanchan Ray, Dr. Sudipta Seal
video icon 60 mins
About
nagarro
Discover more about us,
an outstanding digital
solutions developer and a
great place to work in.
Investor
relations
Financial information,
governance, reports,
announcements, and
investor events.
News &
press releases
Catch up to what we are
doing, and what people
are talking about.
Caring &
sustainability
We care for our world.
Learn about our
initiatives.

Fluidic
Enterprise

Beyond agility, the convergence of technology and human ingenuity.
talk to us
Welcome to digital product engineering
Thanks for your interest. How can we help?
 
 
Author
Martin Dragosits
Martin Dragosits
connect

Disclaimer: The following scenario is not an account of fiction and is based on real-life incidents from the software industry. Any notions of déjà vu are completely intentional.

If you have interacted across teams for any agile software delivery, chances are we have all been in this situation: A developer finishes his tasks during the sprint. From a purely dev perspective, to continue being productive for the typical developer, this is often a matter of writing some more code. The result: As you might have guessed, the developer pulls a new user story into the Sprint Backlog and takes off for another coding retreat.

Spot anything wrong there? This is where Scrum Masters should support the team to find a suitable solution that matches the ideas of Scrum. As a Scrum Master or Agile Coach, you know that this situation can be tricky to navigate. In this article, we'll explore some tips and a checklist to help you guide your team in making the best decisions when faced with this scenario.

Factors to consider for all Sprints

First of all, the team did a commitment at the start of the sprint to complete its Sprint Backlog. Scrum is team sport. The entire development team has a common goal. They either win together or lose together. A winning team also supports each other at every possible opportunity. So, instead of pulling a new item, every team member checks if anybody else in the team needs support.

Besides, a team should never plan out the entire 100% of its time. It must maintain a reserve for any unexpected tasks and some slack time for continuous improvement. Are there any activities which might come up or could need to be done? Are there any activities that have been planned since forever but have barely started? This is the time to pick any such task and ensure that you help your team resolve any legacy issues or tasks and take a step forward.

Scrum consists of increments. We don’t start working on those user stories which can only be completed in the next Sprint. This poses a critical question: Can the new item be completed in the current Sprint? And what does the change of the Sprint Backlog mean for the rest of the team? Especially for the testers. Has everybody been informed? Does everyone feel they can make such a commitment?

Oh, and lest we forget, please do remember to also include the Product Owner in this discussion. The Product Owner is responsible for business goals and what should be achieved. Would there be another user story with a higher prioritization? Is there any reason why the chosen item should not be started at this moment?  

By the way, I heard from a friend, it could happen that a developer pulls a new story without taking these steps, to have a nice surprise for the next Daily. I’m sure this is just an urban legend but then, who knows!

To be prepared for all such situations, I have created a list of questions which helped me enormously in my last client interaction. Going through them also helped the teams to understand these aspects in a much better way. These questions were published in Confluence, with the team having access to them. After some time, I saw them using this checklist themselves. A happy moment in the life of an Agile Coach.

And since Nagarro lives and breathes its principle of “Sharing is CARING,” it’s only fitting that I share this checklist with you too. Please feel free to improve on it if anything seems more well-suited for you.

Checklist for adding user stories during current Sprint
  • What can you do to help the team in completing the planned user stories of the current sprint?
    o    Where could you help somebody? (Did you ask your teammates?)
    o    Is support in testing possible? (Even if you're not a tester)

  • Are there any other activities you could help with? 
    Examples:
    o    Refactoring
    o    Unit Tests
    o    Test automation
    o    Refinement of epics/stories
    o    Improvements you decided in your retrospective meetings
    o    Transfering knowledge
    o    Building knowledge
    o    Documentation
    o    Preparing something for the next sprint
    o    Improving tools, continuous integration, continuous delivery, etc.

  • Can you complete the user story (as per your Definition of Done) within this sprint?

  • Does everybody in the team commit to complete the adapted Sprint Backlog within this sprint? (Did you ask them?)

  • Does the PO/PM commit to pull this user story? 
    o    Is it important enough according to prioritization?
    o    Is another topic being proposed?

Final thoughts

In conclusion, it's important to remember that Scrum is a team sport, and everyone has a role to play in achieving the common goal. While it can be tempting to pull in new work when you have free time, it's essential to consider the impact on the team's commitments and goals. By using the checklist we've provided and working together to find alternative ways to be productive during downtime, you can help your team stay on track and achieve success in each sprint. Remember, with good communication and collaboration, anything is possible in the world of Agile! Learn  more about Nagarro and how we help teams scale their way to success, the agile way

"If the work turns out to be different than they (Development Team) expected,
they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.”

Scrum Guide

Author
Martin Dragosits
Martin Dragosits
connect