.png)
"How many carry-overs do we have from the previous Sprint?” This is typically the question that gets asked during the sprint planning right before the team commence the new sprint.
What is a“Travelling Story”?
I am not sure where I first heard of “Travelling Story”. I want to believe it is from Dave Sharrock when I used to co- train with him while working with Agile42. I stand to be corrected.
Travelling user stories are stories that have passed through more than one sprint. For some teams, I have seen stories carried over for 3-4 sprints ( a 2 week sprint). That means, the team took at least 8 weeks to get a User story to “done”!
The Scrum Guide states that teams deliver “potentially shippable product increments that meet the definition of done” each sprint – but what happens when they don’t? What should a Scrum Master do - in terms of planning - when a story has been worked on, but not completed?
Some will argue that the team should have travelling stories, as long as the work items do not relate to the Sprint Goal and that's because it indicates the team acted and prioritised in the moment, in order to protect completion of the Sprint Goal. However, the Sprint goal isn't that flexible when it comes to change. In fact when a team deviates from the Sprint Goal, it means the goal is no longer viable and the Product Owner could halt that sprint (In a rare case).
However, I believe that bargaining with the Product Owner is what the Developers should be doing to better prioritise the sprint backlog. For instance there is a User story that needs to be expedited, it should be swapped with another story in the sprint backlog which is of lower priority and doesn't comprise the Sprint goal.
During the Sprint Retrospective, Team should be encouraged to carry out “5 whys” to uncover and understand the reason for travelling stories. And even go further to devise a strategy to mitigate the situation in the future. It is more difficult for a PO to plan future work/releases if there is uncertainty whether a team will successfully fulfil their forecast or meet their sprint goal. Some questions that need to be answered are: What problems or challenges did we encounter that resulted in not being able to get ALL stories to done? How could we have handled the changes we had in the sprint
Let’s explore the top reasons why teams have travelling stories on a consistent basis.
Don’t Understand the work: I am of the opinion that if the Product Backlog refinement meets its Definition of done, which means the next ordered product backlog items is ready for the Developers to pull into the next sprint, Sprint Planning becomes seamless. When users stories are not duly refined or pulled into the sprint without contribution from the Developers, it leads to time wasting and prolongs delivery.
Dependencies: This could be internal or external dependencies to the team. Teams either fail to identify the dependencies during backlog refinement or assume that the dependencies will be completed in the current sprint. Assumptions come with risks and need to be validated.
Working in Silos: In a team where there are the “Developers” and the “QAs”, hand off, throwing work items over is often the order of the day. This means the execution of the work is partially completed because testing isn't concluded. I have worked with teams who have product backlog items such as development user story, testing user story etc. User stories are not tested in the current sprint; rather, it is carried over to subsequent sprints. This increases technical debt.
No Definition of Done/Ready: Definition of done is one of the artefact of Scrum and there is a reason for that. When a team doesn't have a definition of done in place or it is not robust, the team will lack collective clarity on what is done.
Wrapping up
Leave a comment below and share the blog on your social media platform as some people might also find it useful. In addition, your gesture motivates me to write more. Thank you.