Scrum planning with multi tiered team [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 8 years ago.

Improve this question

During the past year, our organisation has began using Scrum. Over the past few Sprints it has become apparent that our Scrum isn't really working - we have difficulties with dependencies of certain tasks, and we are way off on our burn down charts.

Historically, we'd never paid any attention to our velocity and complexity of products, and everything was pretty much a guess.

We are nearing the end of our first Sprint on our new project. I have been working over the past couple of days of ensuring that we have a prioritized, complexity estimated product backlog. I retrospectively added the user stories that we are working on in the first sprint. It's quite apparent that we have bitten off more than we can chew.

We estimated our team velocity to be 28 story points, however, we haven't actually finished any of the user stories. Is our team velocity actually zero, and if so, how do I begin trying to plan the next sprint? Do we need to re-estimate our team velocity going into Sprint 2? Or can we take a best guess of what our velocity actually is given the percentage of the user stories we've actually completed?

Another issue we have is that our team is split into three tiers - Data, UI, and Services. This can make Sprints difficult to plan because of the different skill sets. For example, we have a very large user story which involved importing data from our legacy system (almost a whole sprints worth), but only our Data guys are able to work on this story, so we need to add additional stories which will allow the UI and Services team to also be involved in the sprint. We are then stretching ourselves even further.

Not many people on the team understand Scrum that well. I did a Scrum master course about 4 years ago, and I've forgotten a lot of what I'd learned, and I'm really struggling to get this Scrum team working well.

We have a scrum team of 14. Is this too big, should we try and have two smaller scrum teams? We are all working on the same project.

I'd be very appreciative of some advice from seasoned Scrum Masters on what we can do to try and help our Scrum process.

Answer 1

It sounds like the retrospective for this sprint will be interesting! These are some of the things that I might try and encourage the team to focus on in the retrospective:

1. Your velocity is unfortunately 0 because no stories are Done. I would encourage the team to consider:
   • What went wrong with the unfinished stories? What stopped them getting to Done?
   • Were the stories too large or complex? If so, how could they have been broken down? Beware splitting the stories into "layers" - stories should be split into vertical slices so each story still delivers an increment of user value.
   • Did the team start too much and not focus on finishing what had already been started (too much work in progress)?
   • You might need to remind them that the team as a whole succeeds or fails - if one part of the team struggled it was up to the rest of the team to support them and come up with a solution.
2. As discussed above, stories should be vertical slices of functionality, not horizontal ones. This is tricky because software engineers often think in "layers". How can you overcome this with the "tiered" team? In particular, how can you avoid hand-offs between the three groups (hand-offs are expensive and cause delays). Some thoughts:
   • Could the Data team have provided a stub (e.g. an interface that returns hard-coded dummy data) to allow the UI and Services teams to proceed while the data layer is being completed?
   • Could a cross-functional group have swarmed on each story (so all three "tiers" are forced to work together on completion of a story)?
   • How can the tiers cross-train so they can take on work outside their specialist areas (this is the concept of "generalising specialists" or "specialising generalists"). This will allow them to support each other when the going gets sticky.
3. Is the scrum team too large (probably)?
   • A "two pizza" team of 5-9 members is ideal
   • Would it be possible to split the team into two scrums with people from all three tiers in each scrum?
   • Each scrum can work independently on an epic

Outside the retrospective, the scrum master and product owner might want to think about a couple of things:

• Backlog management is really important (and really hard to get right) - it sounds like you have done lots of work on this, but it is vital to keep it up. A poorly groomed backlog will stall the team.
• If you have silos (e.g. between the "tiers"), you need to work to break them down. Silos reduce the team's flexibility and create hand-offs which are expensive.

Finally, "Succeeding with Agile" by Mike Cohn is a really great book which covers the practical side of making scrum work in the real world. I found it extremely useful.

Answer 2

Bids has given good advice and what I consider the answer to the headline question but it is buried in there. I wanted to explicitly call it out:

Would it be possible to split the team into two scrums with people from all three tiers in each scrum?

In Scrum stories are intended to be vertical slices through the system. You should restructure your teams so that they have the expertise to develop the end-to-end features. This will make a huge difference and I would try this before doing any other tweaks.

Not finishing any stories is pretty bad. You should limit the amount of work in progress.

I would recommend that you give the team only one story and make them work together on it. They're obviously a brand new team, that need to learn to walk before they run.

Would this be wasteful by not fully utilizing team members? Maybe, but the team haven't proven they can actually deliver anything. At least delivering one thing would prove a certain level of productivity and it would force them to actually work as a team.