How to decompose Backlog Items for an Integration Team?
Hello Guys!
I would really appreciate some inputs to my problem. So far I have been working (as a SM) with teams that were more close to the business, and complementary practices like user stories or MVP was working just fine and horizontal slicing worked really well.
Now I joined a team where the main work is integration between legacy systems and to research better ways of doing this. Their stories (not even conventional stories for that matter as this is integration heavy), design tasks even spikes have been rolling from sprint to sprint. I tried the following things:
1) Agree with the team that Spikes should be no longer than 2-3 mandays (time bix) where the outcome is either a story, a task or worst case scenario another Spike if at the end of the sprint the subject requires more research.
2) If a Design Task (quite new to me what this is in this specific context) seems to spread over more sprints it should be an EPIC with more related design tasks.
3) If a story is too big (for example 8-13 would require a whole sprint) they should slice it in to smaller, yet functionally valid smaller ones that would fit the sprint.
It seems that it is still not working and the problem is still the same. Now I have been a Business Analyst but their stories are rocket science to me, and I desperate to find a way to coach them to slice better.
Would you have any ideas how to decompose better, where the team is integration focused?
An example: Manage Download Definitions (this refers to a file transfer, manager microservice)
AC: Database Seeding with via 1 command, Data that is coming in should be validated based on the JSON scheme, all integration methods should have an integration test.
Now this one rolled over 9 sprints by the time I arrived and ther eis many-many more. For me this would be an Epic with multiple stories based on the subtasks, but the PO has different EPICS and this is a story of one EPIC and insists on keeping her EPICs as they are.
This is pure chaos. :(
Any suggestions is much appreciated!
It's not clear what the purpose of "Spikes" and "Design Tasks" are, especially in the context of Scrum. These are things that I associate with Scrum's Product Backlog Refinement activity. It could be helpful to use your work management tools to identify specific things that need to be done to move Product Backlog Items closer to a state where they are ready for selection at a Sprint Planning, but they seem to be something different here.
Given this, I'd be looking at their refinement activities. How does Product Backlog Refinement work on this team? Who's involved? How often does the team meet as a whole? How much time are people spending on refinement? What does a refined Product Backlog Item look like? These are some of the questions that I'd be asking.
Would you have any ideas how to decompose better, where the team is integration focused?
Decomposition isn't the challenge. Scrum is not some sort of reductionist activity within which requirements are broken down into chunks and then implemented in Sprints.
What you're experiencing is somewhat reminiscent of Conway's Law. The decomposition of system requirements reflects existing social boundaries in the company, rather than the production of valuable increments. An "integration team", tasked with integration work, then struggles to Sprint in a meaningful way.
Scrum is about learning to build the right thing at the right time, where each Sprint is an empirical learning experiment. Your situation looks like "chaos" because you have no clear line of sight to value, just integration work, and hence no clear means of bringing the inherent complexity of value delivery under empirical process control. Consider:
- What is the impact upon other teams when work is not integrated?
- How do those other teams currently produce valuable Done work without this integration happening?
- Why does integration fall to a separate team -- your team -- as a matter of course?
Hi Thomas,
Thank you for your comment in all cases :)
I know, these are complementary. I have been with them for 1.5 month now and still getting acquired. As a newbie, I focused on getting to know them, their current context, what their work is about, and how they as a team function and what obvious points are there to be improved in the framework.
Anywho, I asked the same question. Spikes are for cases where the PBI needs more clarification on the HOW. So they research and the Spike is part of the current Sprint. Example: prepare - integration related key management processes and tools. Then a related design task (something I still don't get): "Define integration related key management processes and tools". These are also part of the Sprint. In my understanding: Spike is to see what implementation options are there. Design task: How do we plan to implement that option. Then a story out of it, or a task. Hope this helps.
The team is really proactive, they constantly work on refinement (dev-dev, dev-PO). It just seems to me that they need more coaching on decomposing these into sprint sized work items.
Almost forget: we use Jira and Confluence. The PB is of course created by the PO but she already pulls items into the forthcoming 2 sprints as per value. When the planning comes, they already talked about these and the guys make these items as ready as possible. What I mean by this is that they come to a common understanding of it, they add the environment, an acceptance criteria/or expected outcome and an estimation.
Thanks!
Hi Ian,
Thank you for your feedback. I see your point there. What I feel is important to mention and answering your question:
The team is aiming to integrate 3 separate legacy systems (3 separate banks) into one while going into cloud. The situation is not vertical at all, rather horizontal. They are not integrating an application that is being built by them, but they are basically making the bed for any application that exist already or will exist in the future.
I am not fixating on reduction as a main goal, but they are unable to finish their work in one sprint. By the time I arrived (1.5 month ago) many stories/tasks were rolled through 7-9 sprints. So assuming that a big chunk of work like this is possible to be sized better, I don't think that would be an incorrent perspective.
Based on your description, Spikes and at least part of Design Tasks should be considered refinement. By moving these activities to refinement and setting aside some of your capacity each Sprint for refinement, the team will be able to make progress on the valuable Product Backlog Items that can be used to demonstrate progress toward key stakeholders.
I believe that if the team starts making a distinction between "ready" and "not ready" Product Backlog Items and is making sure to have enough "ready" Product Backlog Items going into Sprint Planning, everyone will see an improvement in the team's ability to forecast and meet Sprint Goals without having a lot of work roll over.
You can't necessarily fit refinement into a single Sprint. It takes time, especially if you're considering interrelated pieces of work and making design decisions that impact each other. Moving this type of work to ongoing refinement and focusing your Sprint Backlog on valuable work that can be delivered will be a big improvement. However, it may also reveal other problems that need to be solved.