8

Background

Hi all, I am an experienced SM but I thought I would crowdsource a solution to this from peers. The project is an enterprise scale migration to the cloud with over 500 customers representing 300+ applications.

The backlog is run by a single Product Owner (also a Cloud Technical Architect) who is supported by a BA.

  • Three teams
  • One backlog
  • Each team has their own stand-ups, sprint planning and retrospectives
  • We have a shared Review with customers

Question

When dealing with a single backlog which feeds multiple autonomous feature teams, what is the best way to approach Backlog Refinement or "Play Ready workshops" or [insert generic name for looking ahead activity]?

At present the BA invites all developers from all teams into a single Refinement session to start discussing stories in detail. The devs have, rightly, balked and 19 of the 21 devs just opened their laptops and started coding again.

They have requested an approach where the BA spends time understanding the story in detail through 1-2-1 sessions with devs and only bring those stories to the Refinement session to see if they are ready for Sprint Planning the next week. The BA has balked at this approach since it would be 3 Refinement sessions, also predicting which team takes which stories from the backlog etc.

The Product Owner is swamped conducting technical assessments/communications for the app migrations and has devolved story preparation to the BA's.

They are at an impasse and morale has dropped off a cliff. As the most experienced SM, the other SM's have handed this hospital pass to me to solve.

Out of scope

We have solved a lot of issues in this delivery including operational handover, definition of done etc so I don't want to rehash those.

  • Community, I am probably going to close this question and delete it since it is suffering from the same thing that plagues most Agile related questions; massive scope inflation. I asked how to improve Backlog refinement and instead I already have two answers; one saying 'Scrap Scrum and go to Kanban' and the other saying "Fire your solution architects and let Scrum teams decide the strategic vision of the cloud programme and application migrations." Whilst well-meaning, they are effectively nonsense. – Venture2099 Oct 23 '17 at 14:18
  • Why did they balk exactly, what was their logic? What was the format of the refinement (20 people sitting in a room listening to the PO and BA figure life out)? What's missing from the backlog items that refinement is being done as formal events and not continuously (like most open source GitHub projects - points to lacking a sense of ownership of the work by the team)? I might be confused, but the last sentence in the session seems to say the BA predicts who will take the stories? – Josh Bruce Oct 23 '17 at 14:49
  • 3
    Three teams with one backlog is right. What's probably missing is the Integration Team (if you're following Nexus) or some other coordination mechanism between feature teams. It sounds like the BA is the resource constraint, but how you solve for it depends more on the organizational politics surrounding the BA role than anything else IMHO. – Todd A. Jacobs Oct 23 '17 at 16:24
  • 2
    I won't make an answer since I'm just a lowly developer and I don't have the words to write up a full thing. However, on a previous project of mine in a similar situation (1 BA, 20+ developers from 3 teams) we sent representatives to the grooming meeting and everyone agreed to abide by whatever was decided there. In our case, we sent the team lead and a senior dev from each dev team. Generally this worked since our leads/seniors could talk about any part of the code base with authority. If you're devs are very specialized, this may not work. – Vlad274 Oct 23 '17 at 19:36
  • @Vlad274 lowly developer? Don't be silly. A great suggestion. Thank you. – Venture2099 Oct 24 '17 at 9:56
4

I can see why the devs have balked, as the current approach doesn't sound constructive.

I also don't see an issue with their request as they are basically asking to refine the stories with the right team members or subsets of the overall dev group.

From a BA perspective, and having played the role myself, I do understand the challenges of holding multiple refinement meetings as well.

Two suggestions to offer++:

  • Consider when you're holding the backlog grooming sessions. The BA is pushing back because the current setup probably doesn't allow for sufficient refinement time
  • Treat the refinement as a continuous process; there shouldn't be a need to wait until the designated meeting time if there's something that could be straightened out earlier (this calls for working in conjunction with the scrum master, so interruptions to the current sprint are minimized)

++ The suggestions are from this article, see Options 3 and 4. http://www.romanpichler.com/blog/when-should-product-backlog-grooming-take-place/

3

First of all, I will assume that this migration is the only project that any of the teams have to work on currently.

In order to maintain a Scrum mentality, you need to find "Epics" that can be dealt with in their entirety by a single Scrum team, and allocate the Epics evenly around the teams until the project has been delivered.

If there is absolutely no way that the migration stories can be split into "Epics", then the only reasonable option is to get all the teams working together from the same board with the same schedule. Otherwise you are going to drown the business in Sprint administration. I would drop Scrum and work from a Kanban board, with each developer picking off a task at a time until the project is done.

Of course, your business may not approve of dropping the Scrum methodology.

I also think you have not allocated enough BA resource to the project. One BA cannot support three Scrum teams at the same time, and the BA will become the limiting factor on the project. 1-2-1 sessions with the BA might suit the devs but will be even more time consuming than the single grooming session. There is no need for every dev to be in the grooming session, a couple of representatives from each team should be enough, who can them pass on their knowledge to the rest.

  • 2
    +1 for pointing out that one BA is a potential bottleneck – John MP Oct 23 '17 at 12:52
  • Thanks Baracus although you have tried to solve a problem I am not having. Thank you for your final paragraph though. – Venture2099 Oct 23 '17 at 13:01
  • +1 but I seriously doubt that having 20 people in a meeting is less time consuming than having smaller grooming meetings. It might seem like having more, smaller meetings will take up more time, but they would be much more efficient meetings. Ultimately, requiring less time for better results. – RubberDuck Oct 25 '17 at 21:56
2

Who Owns the Solutions?

In Scrum, the team owns the solution. You mention in the question that the PO is doing a lot of technical assessment. I expect that the BA is then doing some more as they prepare the backlog items. If the team is expecting to just receive ready-to-go solutions, then it should be no surprise that they don't see value in spending time in backlog refinement.

So first thing to solving the problem should be putting the solution back in the dev team's hands - let them to do the technical analysis and plan the migrations. The PO should be focused on the business value and prioritization of efforts.

So Back to Backlog Refinement

Once you do this, the whole conversation becomes much easier. I've worked on some cloud migration efforts before and they're usually fairly complex. Those teams are probably going to need to talk to each other - a lot. If they own the solution, I expect they'll do at least part of their backlog refinement together, then take some of their work back to their individual teams to refine further. LeSS provides one possible solution in this case (https://less.works/less/framework/product-backlog-refinement.html)

  • That is not possible. I appreciate your response but your answer is a massive corporate restructuring of a programme of over 200 people. – Venture2099 Oct 23 '17 at 14:14
2

At present the BA invites all developers from all teams into a single Refinement session to start discussing stories in detail. The devs have, rightly, balked and 19 of the 21 devs just opened their laptops and started coding again.

If you have a couple of mid sized scrum teams, this may work. With larger teams, this becomes very tricky to manage, even by experienced scrum masters. I am assuming these meetings go on forever as well?

With that out of the way, I can recommend the following:

  1. Let each team decide who will attend the refinement meetings from their team. This can and should change from time to time. This way, you will have fewer attendees and a far more focused meeting. Be wary of the teams nominating a newbie just to fill in the blank.
  2. Make sure these meetings do not take more than 10% of the teams' time during the sprint
  3. Get creative and make the meetings with many attendees fun (only in cases where most developers have to attend to provide feedback). Maybe use The Big Wall. This is used for estimation but I don't see why it cannot be used during refinements where for example you group dependent items together in different corners of the wall? This can increase participation. Remember, the main purposes of refinement meeting is to reduce cross-team dependency. You can group unclear/super-large issue into another corner so they can be refined.
0

I assume company is in transformation process. Partially implemented Scrum but haven't delegated responisbilities and product knowledge to Scrum teams. What more this is obviously not possible immediately. This means we have developers who are able to handle technical tasks but they need BA to understand requirements.

What was already said here BA is bottle neck and one need more BAs. If we can't have more BAs maybe we can do something with 1on1 sessions. They are very efficient because we're not loosing time of multiple people but they are blocking knowledge sharing. BA has 1on1 sessions and this means later on grooming only that person knows what is story about. I'd recommend replacing 1on1s with small groups working on related issues to improve knowledge sharing. If each group has at least one person from each Scrum team it should improve understanding of functional requirements in teams. If teams have better understanding and know what they are working on they should be more engaged.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.