Scrum uneven distribution of work hidden in a unified effort

Question

I'm currently a developer at a small software development firm, and we are starting to adopt Agile (specifically, Scrum) philosophies into our culture and project management style. We have only a few developers, so it's important that billable work and efficiency are optimized.

From personal experience, our developers always have more work than our designers, who, empirically, have 60% less work on average per project. If a single user story is estimated based on a unified effort (story point contribution) I see a few issues arising:

1. The designer will always have smaller contributions, thus will estimate lower.
2. The developers and testers will have substantially higher estimations

As far as I can tell, this results in a sprint commencing with a significant imbalance of work, tilting to the developers. This will not be apparent due to a unified estimate.

Instead, is it better to estimate on a per-person level, and stop when the developers have a full sprint. Sure, the designers will still finish early, but at least it's known by their own personalized velocity.

Strict Scrum may say that the designer should work on adding extra value in alternative ways (refinement, code debt in the CSS, etc.) but given we are small, we need to make sure each hour we put in adds significant, just in time value out.

EDIT: This might result in a phenomena of continuously slicing stories into equivalent areas - up to a point - but I don't think that's the point.

Answer 1

trying to wrap my head around this question, so forgive me if I go off base. I'm going to tackle this assuming your billing as a team. I'm going to also assume a designer is a UI person.

The team has a velocity, not the individuals. So your sprint planning needs to be focused on what the entire team can manage in the sprint. If your developers are your limitation, then the sprint is planned to that limitation.

If you try and schedule work to each functional area, you can quickly get out of sync and causing yourself more problems. This happens often when enterprises try and go agile while keeping QA as a separate sprint or even later in the same dev sprint. Unless a QA team has full automation they can rarely keep up with a high performing development team. So the dev team gets farther and farther ahead of QA and that means longer time passes from when a bug is created and when it is identified. The later you identify the harder it is to fix.

So going back to your example, if your designers can get all the work they need to do done in half the time the engineers do, then you've got too many designers or not enough engineers for the planning. Several solutions to this, including: - Cross Training: Designers could learn testing or coding work. A strong agile team has an ability to do more than one role. - Share your designers. Say you have two engineering projects, have the designers working on both. This isn't ideal, as it pulls focus, but often happens with shared resources like Data Base, Localization and such. - Hire more engineers: Get enough engineers to keep up with the designers, ship more product faster. - Reduce designer headcount: One of those elephants in the room no one wants to talk about. Doesn't make it less valid, just less desirable.