Developer To User Ratio

Question

We are in the process of developing an new product and implementing Agile, specifically Scrum. Our first sprint was planned conservatively, but we are going to miss our target by quite a bit. The main cause being interuptions and new clients throwing in last minute requirements that we had stop and react to.

To be able to help identify our weaknesses and also so I can get some fodder together for a retrospective of our first sprint, I am interested in hearing about companies developer head count versus user head count. Is your ratio/mix a successful one? Only for internal development, not software houses or tech companies. Any opinions on the subject are also welcomed, I think it could open an interesting discussion.

The main limiting factor is always budget, so there is no need to include that in any opinions.

Answer 1

User head count / dev head count is not a relevant metric.

You can have a single user that generates huge amounts of change versus hundreds that don't generate any (of very little) change.

What is relevant is the amount of change being requested and how it is managed and tracked.

If you can show how much the requirements have changed while still implementing and designing for other requirements you will have your fodder.

Answer 2

The essence of scrum sprints is that you can't interrupt them with last minute requirements.

Regarding the ratio you are talking about, it depends greatly on what your product is, in which industry you are, and lot of things like that. So to make this value useful, you will have to experiment a bit.

But your developers should rely on your product owner, and not your user base (regardless its size).

Answer 3

developer head count versus user head count

I'll probably get downvoted for that but I think it is largely irrelevant.

There are fantastic products built by a couple of guys serving millions of users.

Just as there are projects developed by a huge strike force which never crossed the threshold of mediocrity.

Answer 4

Too many users is not (should not be) a problem. The developer to user ratio depends on the type of the product and the industry/domain, not on the methodology. Small shrinkwrap products (developed by a minimal team, or even a single person) can have millions of users (e.g. Total Commander), while huge internal enterprise products developed by a team of hundreds can have half a dozen users.

The problem is rather that apparently your users are not familiar with Scrum, and you are not using a single product backlog (or haven't taught your users about it).

You should have a single product owner, who decides about what gets into the next sprint, at the start of the sprint. Last minute change requests are (ideally) not allowed - they can only get into the next sprint. It is the product owner's responsibility to communicate with the users, collect and evaluate feature ideas/requests, prioritize them, and OTOH communicate these towards the dev team. In other words, users should never ask features directly from individual developers; they should turn to the product owner instead.

Answer 5

If you allow new requirements during a sprint for this sprint, you're not doing scrum.

The only thing I would allow, are critical bugs in producitve software. These have to be fixed. Here one would allocate one or two devs per sprint who are responsible for bugfixing, if the need arises.

Answer 6

Sprint is safe zone. At the beginning of the sprint team discusses product backlog items with product owner and selects subset of these items to be done in upcomming sprint. Team commits to these items. It is team responsibility to deliver commited items so no one can introduce new items during the sprint except the team (this usually happens when items are developed faster than was expected).

Each SCRUM project has to have one Product owner (if there is more than one, there has to be hiearchy) which is responsible for product backlog. If the product owner demands new items during sprint the only way to do it is to cancel current sprint and start the new one.

Answer 7

Possibly a more meaningful ratio would be developers : features/projects. If a manager commits all available resources to a sprint, then there is a higher probability that you'll need to interrupt at least one of them for a critical support issue (for instance); it's a slippery slope to things like "well, you're ahead of schedule, so can you slip this extra functionality in", at which point you've broken one of the core principles behind SCRUM.

I get the feeling you're about to start a campaign for more headcount in your department, to relieve pressures on the current team; perhaps a better long term approach would be to manage expectations of your customers (be they internal or external), so that your existing headcount remains flexible to jump in and handle interruptions; at the same time they can manage expectations that additional requirements get deferred to a later sprint.

Answer 8

Don't be too upset with failing your first sprint. It is rare to do anything 100% the first time. Most first sprints reveal problems that have to be fixed - just as it was in your case.

Your problem has nothing to do with the users / developers ratio. Your problem is properly insulating your sprints and making sure the basic Scrum deal (no scope changes mid-sprint, all scope changes between sprints) is adhered to. Things to do:

1. Make sure everyone understands Sprint Backlog can't be changed between Sprint Planning and Sprint Review. If anyone tries to force this play by the book: do abnormal termination, throw away all the work work, plan a new sprint and make all of the fuss about it. The reason Scrum calls for this is to make the cost of interruptions and scope changes highly, painfully visible.

2. Shorten your sprints. Two week sprints worked very well for us because it was pretty easy to explain to any manager type that he can wait 2-3 weeks for his feature. Our PO got pretty good at this eventually.

3. If for any reason you have short fixes / features that can't wait two weeks institute a "firefighter" - devote one developer per sprint to handling such issues, don't plan any regular work for him. To avoid burnout make it a rotating function - someone is the firefighter each sprint. Hey, you could even buy them a firefighter hat. :)

We did 1 & 2 after our first sprint (way back in 2007) blew just like yours. It helped a lot, so we didn't have to do 3. I advised 3 to a team that had such need and it worked pretty well.

Answer 9

One of the biggest mis-conceptions about any Agile methodology is that you can make it up as you go along.

And although this generally true, the key thing is project management and communication.

Like a lot of things in life you can do anything, but there is a consequence. If I buy a Ferrari can I afford to eat?

If I ask for an extra bit of functionality how much is that going to affect the project.

So during planning MoSCoW (Must, Should, Could or Wont) requirements Estimate how long it will take You cannot fill a Sprint / Timebox with Musts or Shoulds

During the sprint / timebox Monitor the time it takes against Estimates Re-plan

When an interruption occurs. Log it and feed this into the Time Taken requirement. Next set of estimates include and interruption factor. Estimation within Agile is an Artform!

When changes are asked for Estimate how long it will take, compare with original estimate Inform the Business User of the effect Prioritise within the MoSCoW

Communication is important. If you want me to add that button there, I will not be able to print the invoice.

Because of MoSCoW it maybe that in sprint 4 the item which is a Wont might make it's way up to a Should or a Must.

Also treat Agile as a toolkit you do not need to prescribe to SCRUM or any other methodology pick the important bits which work for the culture you are in.