Parallel work on new requirements during a sprint – agile or not?
Hello
I work at a company that has invested quite a lot in adopting an agile way of working. My impression is that we are not quite there yet. For example, when we work in sprints, the business analysts (or requirement people) are expected to complete the requirements in one sprint. The developers are then supposed to implement them in a later sprint.
This morning at our stand-up, the analysts had apparently finished a requirements ticket and wanted us (during the ongoing sprint, while we are already working on other things) to also start implementing their new requirement in parallel.
To me, this feels like a very fragmented working context.
To my surprise, everyone else thought it was a brilliant idea.
As I recall, one agile principle is to finish work before starting new work (although I can’t find this explicitly in the Agile Manifesto).
One argument for working in parallel was that being agile means you should quickly be able to switch tasks. But doesn’t that also mean that you would at the same time need to re-prioritize and re-allocate resources to the new priority? I would think that only then you could call it agile, since otherwise you just end up with a split context.
I’m very interested in your input on this.
Forcing discovery into one Sprint that aligns with the development Sprint cadence seems very, perhaps overly, restrictive.
The model that you describe strikes me as dual-track development, as described by Jeff Patton. Most of the way through this article, in the section called "It's happening all at once", there's a nice visual representation of what discovery and development should look like. Discovery doesn't have to be fixed-length iterations.
In Scrum, there's little formal guidance on Product Backlog refinement. However, the output of Discovery can be seen as either the unrefined Product Backlog Items for the Development cycle or well-refined Product Backlog Items for the Product Backlog.
The idea of finishing work before starting new work doesn't come from the Manifesto, but rather Lean principles. Too much work in process tends to introduce waste, such as task switching, partially done work, and hand-offs. Swarming work and maintaining a lower WIP limit tend to help teams optimize their workflow and complete more work in less time.
If you're struggling to switch contexts, that could mean that your Sprint cadence is too long. I'd look at how often your Product Goal is changing or how often your Sprint Goal becomes invalid before the end of the Sprint. These could help determine if your Sprint cadence is too long.
To my surprise, everyone else thought it was a brilliant idea.
What commitments had they made this Sprint? Was the risk to the Sprint Goal ascertained?
One argument for working in parallel was that being agile means you should quickly be able to switch tasks.
Agility isn't about switching, it's about completion with a sense of urgency. That's a very different thing. A lack of commitment or focus would impede this ability. The context is one of empirical innovation and learning to build the right thing at the right time.
One argument for working in parallel was that being agile means you should quickly be able to switch tasks.
I agree with your surprice. Agile is often misunderstood as “we can change anything at any time and never need to commit to a plan.” That is not the intent. Agile recognises that change is inevitable, but it also values commitment. Once a sprint plan is agreed upon, the team should strive to honour it as far as is sensible. Simply adding work into a sprint that was not planned risks undermining the sprint goal and jeopardising delivery.
Another point to consider is that your BAs and developers seem to be working in silos. While some analysis can and should be done upfront, it is valuable to involve developers (including QA) earlier in design discussions. This fosters shared understanding, reduces rework, and improves collaboration across the team.