Should you stop refining items when the development team are confident they will fit in a sprint?
Hello,
Seeking guidance here please. Having started my agile journey at my current company (quite recently too) and having no network outside of it I'm limited in getting opinions of people.
In essence the title is the main question. I have read a lot about swarming and how it encourages the team to work together on an item and can support more inspection and adaption in a sprint. Currently the approach across all teams where I'm based is to break the work down as small as possible, to the point what used to possibly be a task under a user story is now it's own user story. The stance is: the work is a lot more defined, less need for test plans (seperate challenge, all our QA is all manual) and promotes quicker lead times.
My confusion really is it feels like we're investing more time up-front in the refinement to do this when the effort to do some of the 'how' in sprint may be less; do we really need to break work down to the smallest possible chunk even if we know 1 or 2 steps earlier it could be contained in a sprint. In addition with this approach the development team may all be working on elements that are attached to the sprint goal but they are all distinct items and feels less agile as it often doesn't allow for swarming or much inspection and adaption due to the level of detail being refined before being approved for sprint. I should add by, the distinct items effectively means only 1 person from the team can work on that item, so although share accountability to the sprint goal each person has their own user stories to focus on. And again typing that raises another point with this approach around the daily scrum, does it support the right conversations when people are working on what can be perceived as isolated work items.
Thoughts welcome! I do appreciate some of this could be tackled in retro and with conversation which I've tried but the approach is across all teams and its my own uncertainty that's now stopped me from trying to lead this change. My concern is more around are these good approaches or not; do they promote/support an agile mindset or are they just different.
Are they delivering usable increments every Sprint? Are they producing value at a pace that works for the stakeholders? If this process works for your Developers, why does it need to be changed?
The Developers are responsible for the plan to deliver work. They are the ones responsible for the sizing of the Product Backlog Items. So they can, and should, do whatever amount of refinement they feel is necessary.
The Scrum framework does not provide any guidance on the processes that are used. That is left up to the individual organizations/teams that utilize the framework. There is nothing in the Scrum Guide that states all teams have to operate in the same way nor does it say that they all have to operate differently. It is left up to each team to decide how to work.
Product Backlog refinement can be thought of as the art and science of de-risking future Sprints. When the Developers are in Sprint Planning, the question should never be "can we do this work?", but rather one of "should we? Should we do this work in order to meet a good Sprint Goal?". That's what it means for work to be Ready.
Any refinement beyond that point stands to be waste, because order, granularity and detail are being added precociously and too far in advance of that work being encountered. It may be retired from the Product Backlog, having become irrelevant to the emerging product, and the investment made in refining it is then thrown away. Such waste can be hard to justify.
The question is, are your teams incurring this waste right now? Is there any evidence of this?
If you stop refinement when the team has determined that the Product Backlog Item can be done within one Sprint, you are doing the minimum amount of refinement required for Scrum:
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
In my experience, this level of refinement is rarely sufficient. But that doesn't mean its never sufficient. There are a lot of factors to consider. I would tend to look at the risk tolerance of the development organization, the desire for predictability by the organization and/or key stakeholders, and the team's past performance in their ability to craft a Sprint Goal and then execute a Sprint in a way that lets them achieve their Sprint Goal more often than not (where the tolerance for failure to achieve the Sprint Goal is also related to the risk tolerance and desire for predictability of the organization and key stakeholders). The team's practices and way of working also impact how much refinement should be done. I'd even suggest that the team's level of knowledge and skill with their domain, product, and tools will impact the level of refinement needed.
When it comes to highly granular refinement, my biggest concern has been around how much work the team has refined. If they have such detailed refinement for work that, if the Product Backlog remains unchanged, won't be done for a couple of Sprints, they may be refining the work too early. The more detail that you put into decomposing the work, the more likely one of those details will be invalidated before you start the work. This is embodied in the lean concept "decide as late as possible" and the agile principle of "maximizing the amount of work not done" - any of this refinement that is invalidated before you can deliver the work is wasted time and effort that could have been spent on something more valuable.
It's up to the team to decide how much refinement should be done before the Sprint and how many of the decisions can be deferred until just before or even during the Sprint. My recommendation would be to defer as much as possible to within the Sprint, but that exact amount is going to vary widely by context.
My personal opinion - if the Developers are confident that an item can be "done" unhindered in a sprint according to the Definition of Done alongside say 3+ other items in a sprint, that indicates the item is actionable, and I see no sense in making the item even smaller. When items get broken down so much the Product Owner doesn't know what problem is being solved anymore by an item, then Scrum Team has lost the plot.
One exception I can think of is if the Scrum Team isn't confident it understands the examples in relation to the item, as in it doesn't fully understand the problem; then I say bet on the most obvious example first to get some feedback. Consider example mapping.
Another exception could be if the Scrum Team is lacking the evidence it can harvest value from the item ; then consider UX research ia Scrum with Lean UX.
I'm sure there are other exceptions:)
Thanks all, appreciate the time and effort in the responses.
A lot of what has been said rings true. I think the position I find myself in quite challenging as the company only began it's agile transformation last year and the teams are maybe 6 months into theirs.
I think there are a lot of challenges to work through reflecting. Currently the refinement and approach to breaking the items down it more being led by the PO and the people in the team supporting the requirements gathering. (Teams are a bit disjointed with BA&SA in the team but still sort of sat up-stream) I don't believe the rest of the development team know enough or driven enough to challenge this up-front either.
In addition when it comes to sprint planning the PO has the PB ordered but they don't come to the event with a sprint goal, more they set the sprint goal to encapsulate the items they want the team to deliver that sprint. It's worth noting we haven't got a proper PB yet and are refining for the next sprint still; again a problem with how the work is brought to the team by the customer.
Furthermore planning is now more a case of who it going to pick up what as the items are so small generally only person person can look at any given item. It doesn't feel like it promotes collaboration in sprint and the daily scrum loses value as there is little to inspect and adapt.
I think I'm trying to acclimatise to this environment where there are challenges across the business with how we've implemented scrum, specific challenges to the team and my experience is limited to this company only. I'm trying to apply some of the theory in practice, in line with some of these comment but with the factor of external experienced scrum masters who've come on board advocating some of these approaches.
Thanks again, plenty to think through.