How to submit a scope of work if the client's request hasn't event reached the dev team yet

Question

We are an in-house development team practicing scrum. Most of the time, we receive project requests from different parts of the business, we divide it down to smaller chunks of epics, stories, etc. We then give the stakeholders our forecast after our sprint planning as to which are the pieces we think we can deliver.

Now we have a new stakeholder, a different part of the business. They are requesting for a scope of work and a timeline, based on the brief they sent. Question now is this: should the development team already forecast what can be worked on for Sprint 2, 3, 4, Nth, so we can submit a high-level timeline and general scope of work?

Answer 1

It sounds like your new stakeholder is not familiar with your way of operating, and (like many people I have encountered in businesses that claim to be agile) still thinks in terms of waterfall projects with fixed deliverables, timelines and and costs.

There could be a two-pronged approach here. Firstly, document what you think is being requested, and present that back to him for confirmation of his initial request - to show that you are listening to him, and understand what he wants. But don't include any costs or timelines at this stage - you can justify this by explaining that you are not yet in a position to provide these, as you want to discuss the development approach with him.

In parallel with that, make an approach including the senior stakeholders from your part of the organisation to explain the agile approach and the benefits of adopting this. This is an education process so don't be surprised if he doesn't initially "get it", and still wants a fixed set of estimates.

If your new stakeholder won't accept this approach, and there is no alternative, you can still give him your best estimates with wide - very wide - tolerances on time and cost, and explain that these estimates will be refined over time as each cycle of delivery (i.e. sprint) is progressed.

Answer 2

In this situation it is often difficult to talk the stakeholder out of requesting an up-front estimate.

You may find that your best approach will be to go ahead and estimate, but to give the stakeholder a range of estimates based on the level of uncertainty.

For example, your estimates need to take in to account:

• Scope uncertainty
• Discovery - the act of doing the work will likely introduce new work items
• Feedback - the stakeholder may wish to introduce change when they see what is being delivered
• Technical uncertainty
• People uncertainty (people joining/leaving, sickness, holiday, etc.)

You may end up saying something like:

"At the lower end we can do this week in 3 weeks. Given the uncertainty and need to accommodate change the upper end of the estimate is 7 weeks."

Answer 3

It's pretty easy :)

1. First you have to explain your customer the difference between waterfall and agile approaches.

2. If they stick to their solution. You should be responsive and say. Hey, we can try to estimate the Scope of Work, it will take 4 weeks time and will cost a company XXX$. We are being cooperative here. So if you want it we do it.

3. Also don't forget, that when you run out of estimated tasks you can have more estimate sprints if you want. And per your evaluation it would take 40% more efforts if not just going your usual agile way.

4. If they chose waterfall, hey, who you are to judge, they make a task and they will be held responsible for the results. You do your part, let them do their part.

Answer 4

Politely dissenting with the above two opinions, I suggest that you should now undertake to provide the best possible answer to this request – without attempting to "re-educate" the person who is making the request.

It really isn't wrong for "the almighty customer™" to ask you, up front, for a complete breakdown of what you intend to do and how long you think it will take you to do it. I daresay that you would have exactly this expectation from any contractor whom you planned to hire to do any sort of work on your house. (And, as the "almighty customer,™" you very properly would not be the slightest bit concerned with the process that said customer used to manage his or her workmen ... "so far, they only have 'half down.'")

Of course it is implicitly understood by all that there is some element of uncertainty. But, any customer expects competence, and also knows that their negotiating position is strongest at the beginning. Strive now to establish a good working rapport, and deal with "your workmen" later.

"Scrum, blah blah blah ..." To your customer, "that's your workmen, therefore your problem." Quite rightly, they really don't feel the need to be concerned with how you get the job done. Instead, they want to be made very certain that you know (in advance ...) what the job is. And – oh yes, they have learned not to "assume" – that you can actually do it.

Therefore – tackle this issue separately, and use it to your fullest advantage to help you discover(!) what your future "scrum iterations" will actually need to be. Fully explore the parameters with "your almighty customer" before you begin to address the task of dividing the daily tasks among your workmen. (And, recognize that "neglect of this" often turns out to be the cause of project failure!)

"Mind your P's and Q's!!"