Help trying to figure out story output

Dez,

If the question is to you (how many items can you create and send for development), you should be able to assess that, since you are estimating your own productivity.

If the question is how quickly the dev team can complete the items you are sending them, wouldn't that estimate be best provided by those actually doing the work?

On a side note, is this truly a Scrum-related question?   Reading your post, I do not identify anything really related to Scrum.

The question is purely asked to me by my line manager how many stories I can output to server a dev team of 30.

I could have a pop guess at how many stories i.e.if I take a piece of work that I have been given I would say I could do all the analysis up front and have it ready for sign off in a week. But as for how many stories I can output in a week I am unsure how to best present this in a manger friendly way.

Regardless of the projection you make, will it be important for it to be backed up by evidence?

Despite of no signs of any Scrum in your description, I see there a danger that your prediction will be taken as a solid fact by your line manager. Teach him about i.e Cone of Uncertainty, and according to that and your best knowledge give him a huge range i.e 10-50 stories per week / month? I strongly advise you not to give him a specific number.

Hi Dez,

In my opinion, your first step is to understand the bigger picture. Find out the reason for estimating this. E.g., is it for BA capacity planning? Or perhaps to determine development throughput - how quickly the dev team can complete the items as Timothy mentioned? The purpose for this is to avoid the XY problem, and to better cater your answer (including any attached caveats) to the needs of your manager.

In general, you're right that it depends on the complexity of the project, and therefore your understanding on how to best write the stories for it. Apart from that, it also depends on, amongst other things,

• how much detail is expected to go into the stories
• 'definition of ready' for each story (be it implicitly applied, or explicitly agreed)
• the process in producing stories (e.g., do you need to first research it, are developers involved collaboratively or in consultation?)
• the expected quality of the stories (e.g., after having been written, are they expected to later be further refined and/or split further?)
• anything else?

For me, I'd

1. list on a spreadsheet the significant steps needed to write each story
2. have a dry run writing a few stories to get indicative times for each step
3. extrapolate from there the estimated number of stories per week or month in terms of best case, average case, and worst case based on the range of times you get from your dry run
4. include caveats on what could affect the estimation (such as the Cone of Uncertainty as Piotr said)

This way when you present it to your manager, you will also be able to provide a basis for your estimation (i.e., as a form of evidence as Ian suggested). If the estimation later proves to be off, you'll be able to more clearly see what you have missed.

I have two questions for you. 

1. What is your line manager planning on doing with this information?  
2. Is this "line manager" also over the rest of the Scrum Team?

Now I'm going to explain why I asked. 

Echoing others comments, you don't sound like an organization using Scrum.  You may use some of the events, artifacts but you aren't doing Scrum.  This sounds like a manager trying to find ways to pit disciplines against each other.  If this person is over both the BAs and Devs, then your answer is most likely going to be used against the Dev team.  "BA can give you 6 stories a sprint, why can you only do 5?".  If this person is not over both disciplines, I see a rivalry forming.  Your line manager "My BA can give you 6 stories a sprint but your Devs can not keep up. That is why we are behind schedule."

If you are truly doing Scrum, then you need to talk to your Scrum Master and have them talk to your Line Manager.  Have them find out what your Line Manager is wanting and then they can work together so that your Line Manager starts to learn and appreciate how Scrum works. 

Read @Ian's statement over and over again.  He is spot on with his short and succinct question.  If you give one answer and the data shows something else, it will most likely be held against all of you. 

To echo all of the excellent points made previously, perhaps you need to revisit why BA-based throughput is even a valid concern in a Scrum context, since completion/delivery is the end goal (Definition of Done) for any item under the Scrum Framework.

You seem to still be operating under a phased approach (analysis ==> development), complete with all of the inherent and wasteful handoffs.

Are there Scrum roles in your operation?   Where do you fit?   Is there a Product Owner?   Do you have a Scrum Master?