How many user stories per project?

Question

So in an interview recently I had a company ask me to estimate how many user stories my team used per project on average. I had no idea how to answer this. Is there an average out there or an answer? Technically couldn't the answer be anywhere from 1 - infinite?

Answer 1

The interviewer was asking for your experience. There is no correct answer. A pretty normal answer might be "oh, I never calculated averages, but I think the smallest project was about 10 while the largest had a few hundred". Maybe sprinkle in some anecdotes about the 10 turned out to be too few and the hundreds turned out unmanageable. Or anything indicating you have experience.

But again: there is no correct answer. There is only one wrong answer, and that is "I don't know, I have to ask others." I mean, were you there in the projects you supposedly did?

What would you think of a car salesman that when asked what the average price of cars he sold up to now was, then turned to the internet community asking "hey guys, what do cars normally go for?"

I would prepare for more interviews and make sure you indicate very clearly how much experience you have. And if you indicate you have any, make sure you can back it up.

Sorry, there is no direct answer to your question here, because we cannot possibly know what your average is and there is no target you could go for. Just tell it like it is.

Answer 2

TL;DR

I had a company ask me to estimate how many user stories my team used per project on average.

Assuming that the interviewer wasn't clueless or looking for some oddball answer that they thought was canonical, the question was a Bad Interview Question™, and probably asked poorly without sufficient context. However, as a project manager, one often has to deal with X/Y problems like this and dig down to the real underlying questions to ensure a project succeeds. That indicates that this was (deliberately or not) a "thought process" question.

On the other hand, any question based on past data has an answer that can be calculated. While there's no right answer to how many stories a project should have, it's possible to answer how many stories a project (or set of projects) did have. If if asked for a historical data you might use the following formulae:

iterations * velocity = completed story count per project
sum(story counts) / projects = mean of stories completed per project

See the Recommendations section for how you might use the formula within the interview.

General Analysis

The generally-accepted definition of a project contains no universal minimum or maximum for:

1. run-times,
2. features,
3. milestones, or
4. work packages.

A company might create its own definitions to differentiate internally between routine operations, projects, programs, and initiatives, but there's certainly no universal benchmark metric for how many iterations will be required to meet an arbitrary objective.

Therefore, the pragmatic answer is "it depends." A project should take as much time, effort, and resources as needed to meet it's objectives, and no more. But until you define the objectives, and estimate what's required to meet the objectives, you can't answer such questions without digging deeper.

User Story Analysis

User stories aren't specifications; pragmatically, you should think of them as collaborative shorthand for additional conversations. Even if you know what the goals of a project are, and what resources are available to the project, the user stories required to deliver the project will be idiosyncratic to the people working together on the project.

How many epics, themes, stories, or tasks are needed to deliver a project? It depends. The only possible answer here is that a user story should be granular enough to fit within a single iteration. You might have one user story per iteration, or many. You may be able to roll up related user stories to themes, or not.

From a truly agile perspective, the total number of stories for a project is actually irrelevant. The point of the project is to deliver a product. The point of an iteration is to deliver an increment of work. The point of a user story is to help a team collaborate on an aspect of the increment of work.

The INVEST mnemonic helps a team to decompose work into the proper level of granularity to form an effective user story, but in no way constrains the number of stories. The granularity of stories certainly has an impact on how many stories there are, but granularity too is all about right-sizing. A story should be as small as it needs to be to fit within a single iteration, but as big as it can be to carry maximum utility to the project or team.

Recommendations

When asked this sort of question, treat it as an opportunity to exhibit critical thinking skills or to share your professional experience. For example:

1. Explain why the question can't be answered the way it was asked, and suggest alternative ways to look at the problem.
2. Ask questions that add context and detail sufficient to answer the question in a more useful way.
3. Define your own set of assumptions, make them explicit, and then provide your answer within that context.
4. Provide a working definition from your past professional experience, and then walk them through how it applied.

As a concrete example, you might try to answer the question asked by saying something like:

The typical project when I worked at Company X averaged I iterations per project, with a typical velocity of V. I managed P projects, so that means my average project had an average of SUM(I*V) / P user stories.

Alternatively, you might point out that the number of user stories planned or completed has nothing to do with the eventual outcome of the project, and suggest some better metrics or ask more questions about what the interviewer is really trying to learn from your answer.

In the end, an interview is either a conversation (which is good) or a thoroughly subjective essay test (which is less good). If it's the former, show your skills by having the conversation the way you would on the job. If the latter, do your best to influence the outcome, but realize that in the end you can't guess what's in someone's mind, nor can you truly control whether you and the interviewer are fully aligned.