Convincing the organization to use agile estimation

Upper management requires us to provide an estimate based on "man hours" per "role" (e.g. front end dev, back end dev, QA, BA, etc)  then convert it to actual cost.

Why do upper management believe they can impose such a requirement, if they wish to transition to Scrum?

The Scrum Guide says: "The Development Team is responsible for all estimates." The method chosen is up to team members.

I'd argue that your proposed method is just as waterfall as the one proposed by your organization. By frequently demonstrating (or even better, deploying) working software to users or prospective users, you can learn and adapt. The idea of having a set of work that you think is an MVP and working toward that might as well be a waterfall approach toward that MVP. As you demonstrate software, you can continually refine what you think should be in the MVP.

It's a harder sell, but if you want to take advantage of agile approaches, you should determine how to fully staff a team. Perhaps different levels of staffing of a team or a combination of teams. Then, explain that every iteration will yield a demonstration. If things are going well, the customers can reorder and refine the backlog of work. When further work is no longer adding as much value as it costs to run an iteration, the work can stop. Likewise, if the project is not being successful, it can be stopped or paused.

If you're going to take advantage of iterative and incremental software development, it's going to require a new way of thinking of analyzing costs and benefits. Traditional methods won't work as well.

As a Scrum Master, sometimes it is not incumbent upon you to effect change in the organization (i.e. - poor estimation practices), but instead to make visible the folly of such poor practices.

Your management wants estimation based on "role".   Do they view everyone in a specific role as equal in skill, knowledge, and experience?   What is their past success rate in estimating this way?

Do they grasp the concept that some roles may deliver (i.e. - front end dev, back end dev, QA, BA, etc.), but that nothing is delivered as working software to the end customer unless ALL contribute and complete their work?   

An analogy I like to use is that of an automobile manufacturing plant.   You can try to estimate each station (how long it takes to install windows, build a steering wheel, install an engine, etc.), but the only thing that really matters is getting a fully-functioning car out of the plant.   Your upper management seems to embrace the idea of potentially having a lot of unfinished work product lying around (work in progress = WIP).   Speak to them about the inefficiencies of WIP.

Also, your "team" should only be spending time estimating in one way, either in time increments (hours/days), or in relative units like Story Points.   To try and provide both is simply waste, as your team will simply translate story points to time values, and vice-versa.

Good luck!

Upper management requires us to provide an estimate based on "man hours" per "role" (e.g. front end dev, back end dev, QA, BA, etc)  then convert it to actual cost.

In my experience, this is one of the worst ways to actually calculate costs when doing a team based effort (even if using waterfall).  The varying skills, estimating based on little information, and title level based salary scale will vary this tremendously.  The usual recourse is to use some type of "average per role" and inflated estimates to arrive at the cost.  So ....

Why can't your company arrive at an average cost for a team per Sprint. A very simplified example would be (work hours in a sprint) x (average rate per person) x (number of people in Scrum Team).  Notice that estimating the work plays no part in the cost as that will be managed per Sprint based on the customer's input at reviews.  Work with the customers to help them understand that they will be billed time and material based on the actual work done. Make it clear that the customers will be involved in each Sprint Review to guide the next steps in the product/project directions.  This will help them be more comfortable with the approach as they are ultimately in charge of how much work is done. The customer can say "this is enough" at any point. They can ensure that the money they spend will actually deliver the product they need at the time of delivery instead of the product they thought they needed at the time of engagement.  They can also say "this isn't going to work out" and cut ties with no additional financial outlay. If your customers are familiar at all with agile practices, they will understand this concept. If they aren't familiar with it, they will most likely be familiar with time and material cost accounting as that has been around for centuries.

As to the estimation, I feel that everyone else that has responded has covered that topic very well. 

@Ian: The reason they require us Project Managers/Scrum Masters to use that model is to get the amount that they'll use to charge other business units ( clients).

 

@Timothy: This is true. It's truly cumbersome if we will do both types of estimations for every project. 

Do they grasp the concept that some roles may deliver (i.e. - front end dev, back end dev, QA, BA, etc.), but that nothing is delivered as working software to the end customer unless ALL contribute and complete their work?   

I think my managers do, but the organization probably does not. I have always been reiterating that this kind of estimation promotes silo working.

@Daniel: This! We have actually been proposing that we shall be formally creating "Squads" who will be focused on certain project types. The squad members won't be "pulled out" (hopefully) during any sprint. We can also set up a Squad Velocity in which we can use as a benchmark in creating estimates.





Thanks for all these replies guys!