Issue with team commitment without clear design
Hi,
I am a PO of a cross functional team which I have brought together in an organization where SCRUM is usually something that is done by having Front End and Back End specific teams and design is something that happens before and needs to be in place before it can be an item the front and back end developers can work on.
So, i have gotten to a point where the team more and less has accepted that a backlog item now is an item that create user value and more often that not, involves work to be done from both UI, FE and BE. However, i have recently struggled as I wanted to pull myself a little away from being s lot of hands on in the initial design and user flow process and slow that to be part of the work that needs to be done to complete a backlog item. This has resulted in the technical developers not wanting to commit to increment sprint goals, as they don't have a finalized design at sprint start. They argue that as there is no initial designs or flows described they have now idea if it is possible within a sprint and can therefore not commit.
How would you go about such a situation?
Should we go back to making sure that designs are done up front?
An example could be: As a user I would like to be able to register when I have done a task, so I can track my progress and keep traceability.
Then a list of somewhat open acceptance criteria that could be solved in multiple ways.
I would argue that this should be sufficient as a PBI or even a sprint goal, but the technical developers insist they can't commit until a design gas been created.
What to do?
Are you satisfied that the work on the Product Backlog has been sufficiently refined and made ready for Sprint Planning? The behaviour of the Developers would suggest differently.
Judicious refinement is not about doing design up-front: it is about the Developers having the confidence to know the work can be Done. This may require just enough design work to be undertaken in advance of Sprint Planning along with other investigative activities.
Hej Ian,
Thank you for your comment.
I get what you are saying and I can understand the technical developers. How will you then go about those activities of making sure the just enough design is done. If it is not part of a sprint goal then we it might not be done as it might compromised the actual sprint goal.
Could a sprint goal be to produce a design (and test it) to clarify things. E.g. wireframes or mock-ups or a proof of concept (the ladder being more open to interpretation). Would that be an acceptable increment as this would be something that could be validated and use for testing even tough it doesn't go directly into the software? :)
To add to it, my concern is that having a designs up front dictates solutions that is then estimated and committed to.
I would rather that i could state some high-level requirements in a PBI and let the team sort out the details and the how. But it is difficult if they don't want to/can't commit to it :/
I value the team collaboration and the ownership that comes from giving a group of genial professionals a problem or a requirement to solve.
The Scrum Guide makes it clear that Product Backlog refinement is an ongoing activity. Sufficient time therefore ought to be reserved each Sprint to ensure that enough work is ready for the future.
Product Backlog refinement can be thought of as the art and science of de-risking future Sprint Planning sessions. When a team enters Sprint Planning the question should never be "can we do this work?", but rather "should we do this work in order to meet a good Sprint Goal?"
This is from the Scrum Guide's section on the Product Backlog.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
While you might prefer to have a "high-level requirements in a PBI", the Developers appear to want more detail provided. It is unreasonable to expect them to say that they can complete a body of work if they do not have a reasonable expectation of what that work is. You do not get to decide when something is ready to be worked on in a Sprint. The team, and more importantly the Developers, are the ones committing to the work during the Sprint so they should be the ones with the final say so.
I have seen it more common that the UX is done as part of the item refinement and considered part of the requirements. This implies that UX/UI Engineers are actually fulfilling part of the Product Owner responsibility instead of acting as a Developer.
You titled this post "Issue with team commitment without clear design". Honestly, I think that there is an attempt to focus team commitment. Being blunt , given this post and you other one you posted today, I think the real issue is that the Product Owner is not willing to commit to the level of refinement that the Developers feel they must have to be successful. Ask the team to discuss all of this during one or more Sprint Retrospectives. Everyone can come together with experiments that they are willing to try, inspect those experiments, refine them more and try again. Repeat this until things get to a point where everyone is in agreement that the best possible process is in place.
Thanks again Ian and Daniel :)
I think you are right Ian that there might be too much focus on commitment. I actually just cancelled the sprint and we instead planned a sprint that has a clear outcome with a sub-set of the wished solution that the dev team could stand behind.
I think part of it is that the organization/management team is very output focused, which adds a pressure to fill out as much capacity of the entire dev team with outcome focused work/velocity. This has created a culture where it is difficult to give devs more slack time, as a certain velocity expected - and yes I know this is totally brokken and wrong way and I continuously tell them why this is a wrong way of measuring value of a SCRUM team. That means all refinement work ends on the PO desk with a couple of hours help from the team.
Secondly my aim was also to give the team more ownership without dictating too much of the solution. But that ambition is not lost. I just think we need to go about it in another way.
We might have to try as a team to break free from the velocity doctrine and have a talk about needing to have more slack time and not pull in unrefined items - and instead work on these directly on the product backlog instead the sprint backlog