Picking up tickets from a groomed queue and taking them into the sprint instead of planning for a full sprint
Hi,
So I was scratching at this idea. For some time now my team kept facing the issues with spillage. We tried taking less, tweaking our estimation, adding buffer but I feel the core problem lies in special requests half way through sprints or feedback loops that just won't end. Any way, so I was thinking how to make this cycle for efficient.
Here is what I came up with. I know this isn't exactly scrum but I would like to hear out from the more experienced folks here and get some feedback on this.
My idea is to have the same planning session but instead of starting the sprint with a number of groomed tickets, I am thinking of picking up only the tickets as they are being worked on in the current sprint. So basically the "to do" column is the groomed queue in the backlog and the current sprint will have only the in progress, review and done column.
What do you guys think?
How would the team's Sprint Goal be planned for and committed to?
The purpose of Sprint Planning is to craft a Sprint Goal and develop a plan for achieving that goal. Usually, the goal is achieved by implementing one or more Product Backlog Items, so part of planning could be spending time to decompose those Product Backlog Items into more granular units of work and continuing to double-check that your Sprint Goal is likely to be achievable within the Sprint timebox.
I would recommend spending more time to understand the problems.
For requests that come in the middle of the Sprint, how are you triaging them? Why are there so many that are so urgent that they cannot go into the Product Backlog, through a refinement, and wait for an upcoming Sprint?
For feedback loops "that just won't end", I'd want to understand why they "won't end". I'd want to understand what the feedback is and why the feedback appears to be requiring rework rather than future changes that can be put onto the Product Backlog, refined and ordered, and done in an upcoming Sprint.
None of this implies that your idea is bad. It looks like a continuous, just-in-time flow of work. In some environments, this can be beneficial. However, it also runs the risk of turning into a situation where the team cranks out work, rather than considering the value that they add. A key value from the Lean-Agile approach is to minimize waste, and one type of waste is unnecessary work. If you are just queuing up work, it can be more challenging to ensure that there's a deep enough understanding of the problem being solved and how to provide a valuable solution.
would not it a bit like Kanban ? Perhaps Kaban is more suitable Agile technique for teams who can not have a fixed backlog even for one sprint length. In this case having sprint planning is not giving lots of value as the team can not make a commitment anyway, and as a result you can not plan your release or any kind of commitment which scrum would otherwise provide.
But I would agree with Thomas , and try to understand why requests are put in the middle of the sprint in the first place , is there a way to differ them to the end and fix the sprint scope.
I think @Ian Mitchell's question sums it all up. From the Scrum Guide
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
If you pull from a constantly changing list of items throughout your Sprint, how would you define the Sprint Goal that is to guide the developer's work? Would it be possible to create a goal and then pull only the items from the list that support that goal? And if your answer is yes, then why not just do that during Sprint Planning and let everything else fall into the Product Backlog?
You never mention the timebox for your Sprints. But you indicate that the new work coming can't wait for the next Sprint to begin. Maybe experiment with your Sprint length?
You need to help the team understand why there are constantly interrupting work requests. Help the Product Owner understand how to deal with them. The Product Owner is responsible for maximizing the value that the Scrum Team's work produces. Is that really happening?
To finish, I will mention that Scrum is not for all organizations. You may be one of those organizations. So instead of trying to force your workflow into the Scrum framework identify if the framework is right for you or is there another way that will allow your organization to remain agile and provide the value expected/wanted from your stakeholders.
Daniel sorry, but I partially disagree with you. However, you are right, that Scrum is not for all organizations, for the user who asked the question it will be better first to try Scrum and if it is not right for their organization continue to find required framework