We see changes in priorities time to time. With the nature of the team, you might need to expect newer priorities even in the middle of a sprint. New priorities might come as a production issue or a new feature development with higher ROI. I work in a service team where we get high priority items all the time. In this article, I like to talk about how we handle those issues.
What is the ideal way to handle Additional Requirements [real scrum way]
Once a sprint begins, you cannot add requirements or stories to the backlog
It is simple as above; simply you cannot add additional requirements to the sprint once the sprint begins. In addition, you need to keep in mind that if you do not obey at least one rule in scrum, you cannot tell that you are following scrum. Therefore, if you really need to be in pure scrum you need to close the current sprint and prioritize the backlog and start a new sprint with new priority list.
Ideal way doesn’t seems to be efficient for us
As you might already know there are so many hybrid versions of scrum due to scrum been inefficient in some situations. In our case, some team members that get so many ad-hoc tasks (related data base administration). Being a service team, all that members get some amount of ad-hoc tasks. We decided to fork the original scrum and make our own version of it, in search of better efficiency.
We tried so many things and I like share some of the things we tried and how each of them worked out for us. Please remember that being new to pure scrum not all of us were fully cross-functional.
Solution 1: Identify a member that can attend most of those ad-hoc tasks and keep him out of the sprint
Initially, this seems to work well and there was be very less effect on the current sprint from the ad-hoc tasks. With time, we identify that even though there is a separate person for ad-hoc tasks, he needed help from the others for some of the tasks. At the same time, we saw that he was idle on some occasions where there was enough work in the sprint backlog. As he was out of the sprint, it was hard to keep track of him. With all those drawbacks, we decided to get him back in to the sprint and go in search for other options.
Solution 2: Estimating the ad-hoc work in the panning and have a story for it
Our next move was to calculate the time that above person spent on the ad-hoc tasks and try to give an estimate for it in the panning meeting. Here we created an ad-hoc story for the several members and tried to estimate them with the knowledge we have from the past sprints. We hoped that we would be able to give a better estimate in future sprints with experience growth. We identified that this ad-hoc tasks estimates were wrong and it changed drastically from sprint to sprint. Anyway, we continued with this change.
Solution 3: Limiting the sprint length to one week
Limiting the sprint length to one week was one of the best decisions we ever made. With this change, we could hold most of the ad-hoc tasks to the next sprint. Most of the people agreed to wait for 3-4 days to get the task done. Still there were some tickets, which required immediate attention (e.g. high critical production issues). With this change, we observed that deviation in the estimates in the ad-hoc task ticket was reduced. After this, following scrum practices were very much simplified.
Solution 4: Removing the ad-hoc story from the sprint
Even with all the changes, we saw that ad-hoc task had some advert effect on the burn-down and velocity charts. Some sprints did not have lot of ad-hoc tasks but full estimate was counted in the velocity. In addition, these stories did not have clear and well-defined DoDs (Definition of Done ). Therefore, we decided to keep the ad-hoc story out of the sprint and let the velocity fall to some extent. Here some members worked on the ad-hoc tasks and those where tracked the ad-hoc story but not added to the sprint, and will not counted in the team velocity.
With lot of changes and experiments, we decided to keep some changes and decided to revert some. Finally, we went with 1-week sprints and having an ad-hoc story that used to track the ad-hoc tasks outside the sprint. Other than that, we took several actions to make sure we have minimum ad-hoc tasks. We will keep improving our process. I will update this document as we do updates to our process.
- Building strong relation with other teams and getting to know about the upcoming changes before the planning meeting
- We notify all other teams that, we are following scrum and that we are not accepting any tickets after the planning meeting. (Even we take some of them in just tell that you don’t take any tickets in after start of the sprint)
We cannot call this SCRUM anymore. However this version of SCRUM seems to work for us and it helped us in following other scrum related ceremonies and traditions perfectly. We came more close to Scrum by going little away from pure scrum.