Feasibility and Dependency Best Practices for PBIs
Hello Everyone,
I've been in program, product, and project management for the last 7 years or so during which I have been a program, product, and project manager as well as facilitated as scrum master (depending on the company structure). One thing I've noticed is a difference in how many companies approach feasibility and dependencies of new features and I've established some methodologies around this. I wanted to get the community's thoughts on how they handle this by posing the following problem statement:
We are currently unable to verify if a feature is feasible and/or has dependencies for implementation (how to portion) in our Sprint Planning
Follow-up context: How does one make their PBIs independent (see INVEST model) prior to Sprint Planning if the developers have not had a chance to give feedback at this point? There's no set process/event in scrum for verifying this (AFAIK). Sprint Planning covers the "what can we do in the amount of time" as well as the "how can we do it" but has a pre-requisite that PBIs do not have dependencies and are possible to implement.
*SPOILER ALERT BELOW*
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
My conclusion: We host either a "pre-mortem" or initial backlog grooming sessions where Devs can understand what PBIs are coming down the pipeline to ensure there are no dependencies or issues on feasibility. We've also had something similar where both Stakeholders and Devs are in the room during initial requirement gathering. Each has their pros and cons.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
What works best for everyone? Any other methods?
Thanks in advance!
Shouldn’t the substance of your proposal be accommodated in Product Backlog refinement anyway?
We are currently unable to verify if a feature is feasible and/or has dependencies for implementation (how to portion) in our Sprint Planning
In my opinion that feature is not refined enough to be ready to be pulled into a Sprint and considering it during Sprint Planning seems to be a mistake. At best, you could introduce some Spikes to help determine the technical feasibility but even those would be premature if the Product Owner has not identified what it is that they feel the team should be building. Feasibility has many nuances. Is it feasible that this feature would be used? Is it feasible that this feature would actually increase the value that the current users gain from the product? Is it feasible that this feature belongs in another product? Is it feasible with our current technology stack to build this feature in a sustainable way? I would say that a lot of the feasibility study should be done long before the technical feasibility is addressed.
How does one make their PBIs independent (see INVEST model) prior to Sprint Planning if the developers have not had a chance to give feedback at this point?
Plain and simple, if the Developers have not had a chance to give feedback at all then the feature has not been properly refined.
To @Ian's point, this is exactly what Product Backlog refinement is expected to be used to accomplish.
Appreciate the comments!
Sounds like we're speaking the same language and backlog grooming tends to be the spot for this (at least based on the previous two comments). Agreed that these items should not be in sprint planning until they've been fleshed out enough (which is typically hashed out through grooming and pre-mortems for many groups). We've had some success having our stakeholders and devs work together during these as well (especially when the backlog is low and priorities pivot).
Thanks again for your input and open to any other ideas on the topic :)
We are currently unable to verify if a feature is feasible and/or has dependencies for implementation (how to portion) in our Sprint Planning
Agreed that these items should not be in sprint planning until they've been fleshed out enough
I would say it is usually best not to get into a situation where these sorts of items are brought into Sprint Planning, but that's not always the most appropriate choice. It's a risk, but if the perceived value is high enough, it could make sense.
Imagine that such an item emerges from the Sprint Review as the most important thing to do next. The Product Owner could reasonably place it at the top of the Product Backlog.
In such a circumstance, it might make sense for the Scrum Team to discuss it in Sprint Planning and to try to form a Sprint Goal, and for the Development Team to create a Sprint Backlog around it. The Sprint Goal would ideally allow flexibility about the implementation, and the Sprint Backlog could contain several small items that allow assumptions and hypotheses to be validated early in (or throughout) the Sprint.
Scrum is robust enough to cope with this:
- Sprint Planning has a maximum timebox of 8 hours, and much of that time could be used on refinement.
- Sprints can be cancelled once the Sprint Goal becomes obsolete. So if the team plan the work smartly, and quickly find evidence that disproves the feasibility or value of a feature, cancellation is an option.
- A Sprint is timeboxed. The risk of wasted work can therefore be limited to the length of the Sprint.