How can you estimate workload for scrum when you have 4 disciplines in one team

Question

We have been struggling with scrum for quite some time and I actually think one of the major problems is that each story takes multiple disciplines to complete (Design, IOS, Android, Backend). We have all of these people within one team but when creating a story we estimate the story points across the whole story. But then when you calculate how much work the team can do you add up all the time everyone has. But in reality you might have 5 stories each with 20 points work. The team could have 100 points of time in the sprint. But that work could be 2 design, 2 IOS, 2 Android and 14 backend points. Which means you can't get through anywhere near as many stories as planned because you are limited by the roles of the team.

Then you have to bring in stories that can't be completed because the backend person doesn't have time, but everyone else does. So we start to create stories like "Design the interface for blah".

Has anyone got a good way to do this? Also is there a good way in the backlog to be able to record work for the different roles on each story as top level points doesn't help with planning.

Answer 1

20 points work... could be 2 design, 2 IOS, 2 Android and 14 backend points.

There are three ways to resolve this issue.

Option one: Allow more "user" types. Different types of users have different needs (see As a, I need, So that). A user doesn't need to always be a human end-user. Not all features are exposed to the human end-user. So the client and the server can be actors in user stories. A peripheral, like a stylus, headset, or robot that interacts with your app might also be a user. The client developer (iOS or Android) may be treated as a user in a user story such as, "As a client developer, I need an API for data storage so that I can add user data to the database".

Option two: cross training. Scrum encourages team members to self-assign tasks that they aren't the best at, but that they have capacity to help with (see: T-Shaped People). It is better for the UX designer to make slow progress on an update to the client UI code (or to do some quality assurance work or write some product documentation) on a user story that has already been started by the team than it is for the UX designer to begin designing a new UX spec for a new user story that is lower priority and hasn't been started.

Option three: try Kanban. Maybe, for your team, a Kanban approach is a better fit than Scrum. Kanban progresses user stories through a workflow, chosen by your team to fit your organization. Perhaps in your organization you'd want five workflow states: (1) To do, (2) UX design, (3) Client, (4) Backend, (5) Done. If you pick this approach, consider what states a user story should move through and what sequence handoffs of primary responsibility should occur in.

Note: the objective of either Scrum or Kanban is increasing the team's ability to make reliable customer delivery commitments and responsiveness to changing customer needs or feedback. The objective is not to keep all team members 100% busy 100% of the time. So if your UX and client people are only busy two days a week and backend person is working seven days a week, then you don't need to change your estimating you need to hire (or cross train) another backend developer. Or you may need to choose an alternative technical approach, like moving to a PaaS or making better use of an open source library, or eliminating a feature that users really don't use.

Answer 2

I've had to deal with this same issue in game development for years (art, design, dev), and my current best approach is to simply get a separate estimate for each non-overlapping discipline. This introduces challenges in leveling the capacity across a sprint (it becomes more puzzle-like), but it uncovers "largely lopsided" items and increases your ability to capacity plan long-term, spot skill set shortages, etc.

That being said, it looks like your team makeup may not be quite as disparate?

Answer 3

I don't think the issue is with estimating, but with how cross-functional your teams are. Combining multiple disciplines is just not the same.

• Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;

• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

Henrik Kniberg defines cross-functional team this way:

Cross-functional just means that the team as a whole has all skills needed to build the product, and that each team member is willing to do more than just their own thing.

Designing just the interface will also not help as you are not delivering "working software", since I guess the interface is useless without the back-end.

Seems there is a bottleneck in back-end development knowledge, either get more back-end developers in the team or get the iOS and Android developers to also gain knowledge of developing back-end services.

Think about what happens when the back-end developer "Gets hit by a bus"(-factor). Now the team will never deliver anything anymore ever, until you find a new back-end developer.

Find a way to train the other development team members to be able to deliver fully functional features even without the most experienced back-end team member. This guru should be the goto-guy, not the do all the work on your own guy (or girl ;-).

Also when you describe your team like consisting of "different roles", the first thing that comes to mind is you might be creating a "mini waterfall" workflow.

Answer 4

Reading your question, I'm going to make two assumptions:

1. Growing real multi-discipline skills in your team isn't an option. I.e. back-end engineers doing design is usually bad for everyone.
2. Expanding your team is not an option.

I would suggest the following:

1. Have some good team discussions about it. In true scrum fashion: how does the team think this issue would be best solved?
2. Motivate the team and product owner to split the user stories. Explain how this will clarify dependencies on expertise and eventually getting more stories done, delivering value.
3. Think ahead during sprint planning. If the stories have been split, and it's obvious that they all require one specific team member / expertise, take action. The whole team should agree that the sprint backlog is workable for all. If that's not the case, make the product owner and team shift stories in the sprint until they do.
4. Find common grounds or easily learned skills for team collaboration. For instance: the back-end developer might not be able to photoshop a design, but with some guidance will be able to create wireframes.

Finally, if every sprint has enough stories for two backend dev's, and it's always that same backend expertise domain overflowing with work, hiring another backend dev might make sense. Especially when it helps you deliver, add value, grow your business.

Answer 5

Can I ask is somebody planning the estimates or are the developers / testers / etc asked to do their own estimates. The only way you can get accurate estimates is to ask the people who are doing the work to estimate the work as a team. I have used planning poker - have you tried that. Have a look at the link below. https://www.mountaingoatsoftware.com/agile/planning-poker

It is better to estimate using agile methods or a recognised project planning methodology. Stick with the methodology and you can't go wrong.

Answer 6

I tackle this by doing the following:

1. Break the user stories out into value delivered and by discipline. This lets you still hit the mark of the user story delivering a value and breaking out the estimations in a way that will let you do effective sprint planning.
2. Group user stories as features. When breaking out the user stories by discipline relate them back together as a feature, which is what you will ultimately deliver. This lets your stakeholders see the big picture of what you are working towards.

3. Tackle infrastructure/design work in an advanced sprint. If you are finding that you have a bottle neck being caused by the same part of the team (i.e. design or infrastructure work) then explore bringing that work in a sprint early. This will let you chain your work and ensure that you do not have folks twiddling their thumbs. For example:

   • Sprint 1: Designers are designing "Feature B". Developers are working on "Feature A".

   • Sprint 2: Designers are designing "Feature C". Developers are working on "Feature B".