Introducing Work Late into Sprints: How to report on it in Jira, the perils of doing it and how to avoid it
- Danielle Downs
- 3 days ago
- 9 min read
Updated: 1 day ago
Identifying the problem
For a while, I had suspected that work being "sneaked in" to sprints late (i.e. after the sprint had started) was a problem, but it is extremely difficult to report on in Jira.
Frustratingly, Jira can identify items added after the sprint started and they are denoted in Sprint Reports by a * , but there is no JQL query or parameter by which you can filter to easily report on the data.
According to feature requests for both cloud and server-based versions of Atlassian's Jira Platform, it is not built-in and judging by the fact that both requests remain in "Gathering Interest" state, despite being raised in 2018 and 2019 respectively and the former attracting nearly 1,500 votes, it doesn't look like the capability will be developed any time soon.
Necessity, as they say, is however the Mother of all invention and desperation ultimately led me to create my own handy, albeit slightly cumbersome, workaround, which I share in the expandable section below, for those that are interested. For those that are not interested, or don't use Jira, feel free to skip to the rest of the article.
How to produce metrics on work added after a sprint started in Jira
Go to the Sprint Report for each completed sprint.
Copy & paste the contents of each section of the report into Excel (NB"View in issue navigator" and exporting doesn't work because the * are not displayed):
Completed Issues
Issues Not Completed
Issues Completed Outside of this Sprint
Items Removed from Sprint (optional if you don't want to include items that were added to and subsequently removed from the sprint)
Select "paste text only" to avoid the Issue Type icons appearing in your spreadsheet as images and prevent the IDs being displayed as hyperlinks that can annoyingly be inadvertently clicked.
Delete the rows that don't have an * beside the ID. It is much easier to see them in Excel than on the web page, which is why I prefer this method to manual counting, which gave me a migraine.
Rinse and repeat for each sprint on which you wish to report. If, like me, you want to report on a number of historical sprints retrospectively, I recommend adding a column to the left of the data and entering the corresponding sprint ID beside each row and copying it down for each sprint report that you add to the list.
You can now create a pivot table showing a count of items added to the sprint after it started, by issue type and/or status at the end of the sprint.
If desired, you can add a "Summary Status" column to summarise the various Jira statuses to simply "Not Started", "In Progress", "Resolved" and "Blocked". To do this, I used If statements to map each Jira status to a summary state but, if you don't want to retain the original data, find & replace is probably a quicker option.
If you want to report on any other information (e.g. Reporter, Assignee, Labels or Components) that isn't included in the Sprint Report, you have to "join" the list of IDs generated above with the output from another JQL query.
To do this, I copied and pasted the list of IDs (with their asterisks) from the Excel document created above into a new worksheet.
I then used the "Text to Columns" function in Excel, with a "Fixed Width" delimiter, to reduce the column to only the issue ID and remove the asterisks (NB you can't do a simple find & replace because Jira, in its wisdom, used the wildcard symbol * which is ignored by Excel in this scenario).
I then copied and pasted the list of IDs into Co-pilot (other AI tools are available) and asked it to turn it into a comma separated list. I could then copy and paste the list into Jira's JQL query field with a simple KEY IS IN (ABC-1234, ABC-2345..) string. I could then add the columns I wanted to see into the report, export it to Excel and from there, create a pivot telling me anything I wanted to know about work that had been added late into a sprint.
The perils of introducing work late into sprints
Now armed with 12 months' data on how much work had been added late into sprints, when and by whom, as well as the outcome for that work at the end of the sprint, I felt equipped to tell my team why I keep bleating on about it being a bad idea.
In order of severity of impact (in my humble opinion):
It doesn't allow time for effective refinement
If a story is added into a sprint after the sprint has started, it limits the opportunity to effectively refine it with the person or team that will be doing the work.
This can result in work not being well-understood and time being wasted, or the story being blocked if the relevant pre-requisites are not in place in time to start work.
It undermines the Scrum principle of commitment
When a team commits to the work they will undertake in a sprint, they do so on the basis that they have capacity to complete the work.
If more work is pushed into the sprint without work of equal or greater estimated effort being removed, it undermines the trust between team and Product Owner because they feel pressured to complete additional work on top of that to which they have already committed.
If it happens regularly, it can lead to low morale and devalue the sprint commitment process, resulting in teams deliberately under committing because they fear, or even know, more work will be shoehorned in.
It increases WIP and puts the Sprint Goal at risk
As well as undermining the team's trust, putting additional work into a sprint obviously reduces the team's capacity to complete the work already planned for that sprint and can therefore put the sprint goal in jeopardy.
Of course, there will be times when a change in business priority is such that the sprint goal may need to be modified mid-sprint, but such occasions should be very rare and not a common excuse for work being introduced late.
If work is already underway when the team is asked to take on new work, it can also increase Work In Progress (WIP) and spread the team more thinly across the work to be done. This can result in stories being unfinished (or "80% done") at the end of the sprint and dramatically reduce, or even nullify, the value ultimately delivered at the end of the sprint.
It skews the burndown chart
When scope is increased mid-sprint, it counteracts the impact of stories that have been done on the burndown chart and can even turn it into a burnup chart!
Yes, you can tell from the scope line that scope has increased but, if more work is added than has been completed to that point, the burndown line will go up, instead of down and may unjustly appear to flatline, even if steady progress is actually being made. This misrepresents the team's progress and can have a negative impact on morale, as well as stakeholders' perception of the team.
How to avoid introducing work late into sprints.
The best solution depends on the root cause as to why the work is being introduced late:
Change in business priorities
This is usually outside even the Product Owner's control and the only alternative is to:
Refine the story or stories as diligently as if they had been planned.
Don't be tempted to rush refinement to start work as soon as possible.
Ensure the work is well understood, estimated and all dependencies resolved before it is taken into the sprint.
Remove work of equal or greater estimated effort.
Talk to the team, ask what they think needs to be removed if they are going to be able to deliver the new work being asked of them.
Don't pressure the team to agree to taking in the work without taking anything else out, as it is unlikely to result in everything being delivered.
Some rare circumstances may warrant a temporary suspension of sustainable pace and the team may be open to that option, but it has to be agreed and not become a regular occurrence, or you risk losing the team's trust and honesty when it comes to future sprint commitments.
Be open about risk and consequences.
If the change in priorities puts the sprint goal at risk, be honest to stakeholders and explain that it is an unavoidable consequence of the work being added.
Flagging the risk early will be perceived much better than using it as justification for non-delivery at the end of the sprint, when it may sound like an excuse.
Late discovered work
Late discovered work is a sign of poor planning and means more time and consideration must be given to PI / Release Planning and backlog refinement, to ensure all work needed to meet the PI or sprint goals is captured just-in-time before the sprint starts.
If it is completely unavoidable, the same principles apply as to a change in business priorities:
Don't try to shortcut refinement.
Be honest about the discovered work and prepared to negotiate on lower priority work.
Don't be tempted to finger-point or disguise the fact that additional work has been uncovered, no matter whose fault it might be.
Trying to "sneak work in" or increase the scope of stories already in the sprint won't earn the team's trust or make any difference to the ultimate outcome.
If you're honest that a mistake was made, the team will be more likely to want to do what they can to help, than if you come across as defensive or (worse!) try to make them think it was their fault.
Imagine that it was undiscovered complexity or a bug that was found, instead of new work. How would you want the team to bring it to you?
Other work in the sprint is blocked
Bringing more work into the sprint is not always the solution here.
Focus on resolving the blocker or dependency before bringing in more work.
By defnition, if something was committed to for the sprint, it was of higher priority than anything on the backlog, so the focus should be on unblocking the higher priority story, vs. taking lower priority work in.
If a story is blocked due to an individual's lack of availability, capacity or capability, ask other team members or resources outside the team to help, rather than look for alternative work.
If the blocker cannot be resolved within the sprint, it's ok to replace it with other work of equal or lesser effort from the backlog
The blocked story must be taken out and put back on the backlog, with a view to bringing it into a future sprint, once the impediment has been resolved.
This is another good reason (if you need one) to always have at least 4-6 weeks' worth of refined stories on the backlog, just in case they need to be pulled in.
Unexpected increase in capacity
It's unusal but it can happen that additional resource unexpectedly becomes available, a story is no longer needed, or turns out to be less effort than first thought.
This is probably the only "good" reason for bringing unplanned work into a sprint and is obviously ok, providing all the other work planned for the sprint has already been completed, or will be able to be completed comfortably by the end of the sprint.
If pulling work into a live sprint from the backlog though, always remember:
It still has to be refined, well understood and meet the Definition of Ready.
Again, this is another good reason to keep at least 4-6 weeks' work ready to go.
Don't bite off more than the team can chew.
Discovering unexpected capacity in a sprint can cause euphoria, resulting in over optimism and overcommitment.
Make sure that any work taken into the sprint can still be achieved within the time remaining.
Consider alternatives to taking in more stories.
If there are no stories of a suitable size on the immediate backlog, consider spending more time refining the backlog or doing a "spike" in preparation for the next or a future sprint, to help it go more smoothly.
Summary
If, as an Agile Coach, Practitioner, Scrum Master or Team Member, you suspect (or even know!) that a Product Owner is pulling unplanned work into sprints after they have started, try to gather data on the severity and volume of the problem, as well as the impact it is having on your ability to meet sprint goals.
Raise it at a Retrospective and be sure to focus on the impact, rather than the annoyance or "bad practice" factors, which can appear to be self-serving and /or hypothetical.
If you are a Product Owner or Manager and know you're guilty of this particular anti-pattern, please consider my advice and look for alternatives to pulling work in mid-sprint.
If you do have no choice, make sure the work is still well-defined and be open and honest with the team and stakeholders about the impact of bringing it in. Raise risks sooner rather than later, when they might be perceived as an "excuse" for non-delivery.
Most importantly, don't be tempted to force a quart into a pint pot, as it won't prevent the contents from overflowing! One-off oversights can be forgiven but repeatedly asking the team to accept unplanned work into a sprint will undermine their trust and may result in under commitment in future sprints.
Comments