Multiple definitions of done within the same team
Hello!
I'm new to a team.
In this development team (of 12 people) , there are many different skillsets. Dev, UX, BA, Solution designers, QA.
PBIs exist in the backlog, split by discipline. UX tickets for UX, BA tickets for the BA etc.
Sprint goals tend to exist based on individual delivery of sprint backlog items from the respective disciplines (i.e. it's rare for the separate disciplines to work together on the sprint goal within one sprint, rather the sprint goal tends to be focussed on working software, which will have been as a result of all the disciplines working on an item at some point, but over the course of multiple sprints)
There is only one documented definition of done.
All disciplines add story points as part of refinement and planning in order to inform sprint planning activities. These story points are used by the PO in order to forecast when items are likely to move to done. The PO states this is a way of working that the team has ended up at due to the need to provide accurate forecasts. (There is no evidence to support that the dev team has actively pursued this way of working).
My perspective
In this team - we essentially have only a subset of the dev team capable of taking a PBI from "Ready" to "Done" within the sprint (That is to say devs and QAs).
All other disciplines are engaged in the process of ensuring that a PBI is "Ready", and rarely assist or contribute towards the process of moving an SBI to done, or contribute towards the sprint goal. This means that in effect, there are actually 4 definitions of done in the team, although these are not documented.
Having 12 people in scrum events feels unwieldy and results in certain disciplines sitting there without anything to discuss for most of the event. This has previously been mitigated by the team being assigned PBIs to refine, then doing this in isolation before reporting back to the wider team.
There has been some indication that the above is successful, however it is not clear if this is as a direct result of the approach (correlation not being causation)
My Issue
I feel there are a number of negative factors in this approach
1) The split disciplines and hand offs mean there is little opportunity for the team to work together on a sprint goal item. As a result, many team members are alienated from discussions on sprint goal work because they cannot assist in moving sprint goal related PBIs to done.
2) The use of story points appears to be inaccurate and unhelpful for complicated but not complex items (i.e. ux, solution design, BA)
3) It feels like some of the immutable aspects of scrum are being breached - specifically the definition of done
What approach would you recommend to be empirical about this? How could I capture relevant data?
How could I facilitate a team discussion bearing in mind they are wedded to this way of working.
Your thoughts are appreciated!
I'm curious about what these Product Backlog Items that are split by discipline look like. This could indicate a few things, but I'd be most concerned that the PBI is not a representation of something needed in the product, but rather a description of some task or work to be done. If it does represent something required for the product, I'd want to understand if each one, completed individually, adds value. The description of the Sprint Goals being tied to individual delivery of items also seems like there's not a cohesive, product-centric description of the objective of the Sprint.
Overall, it doesn't sound like you have a team. You have a bunch of individuals doing their work that may contribute to a broader vision. There doesn't seem to be a lot of ownership of the work and way of working or a focus on delivering value regularly. The focus seems to be more on outputs rather than outcomes and value.
I'd want to understand why the team and organization are wedded, as you say, to this way of working. Might there be opportunities to change their way of working in a way that makes the team more productive?
Hi Thomas thanks for replying, really appreciate your thoughts on this.
An example of the PBIs would be:
1. complete business analysis for customer dashboard
2. Complete UX for customer dashboard
3. complete solution design for customer dashboard
4. complete dev work for customer dashboard.
(This may span over 2-4 sprints in total before number 4 is fully complete)
Those sound more like tasks needed to deliver a customer dashboard than individual stories. The purpose/goal of user stories were to define a situation that needs to be addressed in order to deliver value. You are defining the process that needs to be undertaken in order to deliver value. And there is nothing potentially releasable being produced by 3 of those 4 stories. And I'd be remiss if I didn't say that you have just defined a waterfall project plan. You aren't using Scrum, you are doing a waterfall project with a fixed cadence of checkpoints.
What approach would you recommend to be empirical about this? How could I capture relevant data?
Use a Kanban metric. Track the cycle time (time from when you start working to the time it is done) for a feature, in your example the customer dashboard, not individual stories. See how long it is actually taking you to complete that work. Then work with the team to see if they could come up with any techniques that might shorten that duration. Shortening the amount of time it takes to deliver value actually increases the teams ability to deliver more value.
Facilitate discussions with the team on specific features (customer dashboard) about whether there was time wasted. For example if the business analysis item was completed in the first 2 days of a 2 week sprint, that item sat idle for a very long time. This is waste. Is it possible to change that behavior so that the wasted time is eliminated or at least shortened? Analysis might show that the business analysis and UX could be consistently done in 1 sprint instead of 2. Then start pointing out that in reality both of those activities should be done before an item is ready to be worked on and explain that is actually the act of refinement.
As a Scrum Master you should help them appreciate the benefits of Scrum but you should also point out the detriments associated to their behaviors.
Sprint goals tend to exist based on individual delivery of sprint backlog items from the respective disciplines (i.e. it's rare for the separate disciplines to work together on the sprint goal within one sprint
The Scrum Guide says: "The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives."
I'd suggest that what you have described might not be a Sprint Goal.
What approach would you recommend to be empirical about this? How could I capture relevant data?
Is the team delivering integrated product increments of release quality each and every Sprint?
How could I facilitate a team discussion bearing in mind they are wedded to this way of working.
Will there be consequences at some point, if inspection and adaptation does not occur, and value is not maximized?
Show this youtube video to your development team. There is only one Definition of Done per product. They may have confused Acceptance criteria with Definition of Done.