All, I have to work with an Agile team that they have to attend to live system issue(tickets) fixing while working on a sprint. So that we cannot achieve the committed SP at the end of the sprint. Does anyone have advice for such an issue?
-
Potentially dup of Applying agile in a mostly operations/support environment– Tiago Cardoso ♦Mar 31, 2019 at 13:24
-
Is the amount of support required highly variable? Otherwise, velocity calculations should automatically compensate for this. Are you using velocity in your planning? Are you planning with some kind of story points, or based on time required?– ErikApr 4, 2019 at 5:41
-
You don’t commit to a fixed number of story points. You commit to a Sprint Goal.– Todd A. Jacobs ♦Apr 6, 2019 at 4:28
Add a comment
|
5 Answers
The very first thing you should do is make it visible how many support requests the team has had to tackle and how much time that took. This allows the stakeholders to see exactly what the effects are of the support requests.
If the time spent on support requests is fairly consistent over a longer period of time (or it feels to be that way to the team if you have no measurements), then you can take that into account in your sprint planning and simply reserve time in the planned work to respond to support requests. This should make it possible for the team to feel a sense of accomplishment that they can finish what they promised.
Lastly, not all problems in a live system are equal. While some problems are definitely blocking for the business (for example, when users can't login to the system, causing the business to lose money), others might be less severe (like a typo on a rarely visited page).
You should try to get all problems rated to the correct severity. Blocking issues are important enough to be picked up immediately (to the point that you can even consider aborting a running sprint to free up the resources), but less severe issues should go on the product backlog and be prioritized along with the rest of the work.
To get this done in the organization might be a struggle, especially if they are used to getting all production issues fixed with the highest priority.
If (truly) blocking issues are a frequent occurrence, then you should also try to analyze why those problems happen so frequently and what can be done to reduce their occurrence rate.
answered Mar 30, 2019 at 19:44
As you're working with sprints, I assume you're working following Scrum framework.
Your question then might be "in Scrum, how to commit to a closed iteration if you don't know what'll come mid Sprint?"
Answer: you can't.
Scrum is based on the idea that, once a specific piece of work is committed to be delivered, it'll be the only work the team will have to deal with.
There are a few alternatives to handle such scenarios:
- Go full Kanban and forget about iterations. Requires more mature teams.
- Split capacity between support and development and go Kanban for Support and stick to Scrum for development.
Personally, I see Kanban as the evolved version of Scrum for mature teams. With that in mind, discuss with the team on how to move towards less iteration-centric development models.
answered Mar 31, 2019 at 13:40
Based on your several previous sprints, you should know (or gather) the average amount of such tickets and actual story points / hours spent.
Then during sprint planning you allocate certain capacity(e.g. 15-30% of average team velocity) to those unplanned items.
If there would be more unplanned items, you would collaborate with PO to put some items back to backlog.
If there would be less, then again PO could put something to the sprint which teams are confident to handle. This could also be non-functional items (extend unit test coverage, improve project build time, sw performance, technical debt, other enablers for future success)
The committed SP by the team has to consider both the stories from the product backlog, and portion of committment towards the production tickets. The sprint planning should be like say 85% product backlog and 15% for these defect fixes.
As Scrum is based on the empirical approach, I would treat such things as the feedback to the current work and try to learn from such cases. It would be wise to add people who raise such tickets to the stakeholders list so the Product Owner (PO) would have a better overview of them.
The PO should always maximize the business value of the Development Team's efforts; it may seem insane but sometimes this means that it's more beneficial to continue the work on the new and leave some issues / bugs / crashes for later.
When you are not able to reject such work, a Sprint content is always negotiable, so the PO and Development Team should have a conversation about what is possible to achieve within the Sprint.
Once you need to spend 15% - 30% of the work on maintenance, take a trace of the amount of such work and think over what you can do to make this smaller in the future.
