Developers have bandwidth to pick up new story
Hi all,
Just need to understand how this particular situation needs to be handled from scrum process perspective.
Our sprint lasts for 2 week (total 10 working days). Starts on Monday and ends on the following Friday. Other than the stories (demoable + testable) we pick in the sprint, we also have a dedicated sprint buffer story that tracks my teams effort spent on misc activities (like some POC or RnD work)
One of my dev is having some bandwidth and wants to pick another story . My sprint is ending tomorrow. He has asked me whether we can create a new story today, and go for a spill over since it can be coded within the 2 week sprint time frame but not be testable by tomorrow. he asked me to move the testing bit in the next sprint.
To avoid a spill over, I suggested them to track their dev effort for this particular story in sprint buffer. As of now sprint buffer is estimated to be 5 pointer. I have asked them to change it to 8 ( 3 pointer for new story). We will create a new story in next sprint that will only take care of testing since the coding would have already been completed.
Does my approach works? Or should i have gone for a spill over?
Thanks
I think that the idea of a catch-all buffer item is a key problem. One of the pillars of Scrum is transparency, and two of the values are openness and focus. How does the idea of a generic buffer promote transparency, openness, and focus? It doesn't seem like it does, since it's unclear what the team is currently working on to stakeholders who want to understand what is being done toward delivering value. It also doesn't ensure that the team is focused on delivering the most valuable pieces of work earlier.
I would recommend stopping this idea of a buffer and actually capturing not only stories (which I'm guessing represent either new or modified pieces of functionality), but also any tech debt paydown and risk mitigation and learning and prototyping or proof-of-concepting work as individual items in the Sprint Backlog, and the Product Backlog where appropriate.
My advice is to dismiss the idea of "spill-over" altogether. In Scrum, there is work to be Done and work which remains to be done. Work which remains to be done does not "spill over" anywhere. Rather, it should be accounted for on the Product Backlog where it may or may not be planned into a future Sprint.
If the Sprint Goal has been met along with any other commitments, then there is nothing to stop a team member from bringing new work into progress, and without intending for it to be completed that Sprint. Any remaining work ought to be accounted for by re-estimating the relevant Product Backlog items. The induction of any new work must not put the ability to release a "Done" increment at risk.
If there is a likelihood of newly started but unfinished items being completed in the next Sprint, this technique can help to optimize the flow of work across the Sprint boundary.
I agree with both @Thomas and @Ian. "Spill over" is not a good thing to get into the habit of doing and "buffer" items just leads to hiding work. As @Ian said, anything that isn't finished within the Sprint time-box should be evaluated as part of the Product Backlog. It may be added to the next Sprint or it could remain in the Product Backlog for future consideration. I suggest that these discussions usually occur during the Sprint Review so that there is transparency provided to the stakeholders as well.
On the buffer topic, I usually coach that the team pulls in only the Product Backlog items that produce the potentially releasable increment targeted for that Sprint. It is possible, and has occurred, that the team will view the Sprint as "light". But it also allows for discovery of new information. Planning for 80 hours of each individual's time usually does not end well. If the team finds that they have some available time to work on new items, then they should feel free to pull in additional work. Notice that I said "the team" and not "a developer". If one person finds themselves with time, it is better to have them first focus on ways to help the other developers finish work related to the Sprint Goal. If there is no need for that help, suggest that the individual spend time working with the Product Owner in refinement of the Product Backlog Items. There is often information that developers can provide the Product Owner that aids in their understanding. If those two opportunities are not needed, then a discussion should occur between the Development Team and Product Owner on pulling something else in to the Sprint.
I agree with all of the above comments from Thomas, Ian, and Daniel.
One additional concern though:
As of now sprint buffer is estimated to be 5 pointer. I have asked them to change it to 8 ( 3 pointer for new story).
As the Scrum Master, why are you making any recommendation to the Development Team regarding their estimation of work?