Product Owner and Business Analyst: giving an estimate before breaking down to tasks

Question

I'm used to work using agile methodology for a few years but there is one thing that keeps me thinking.

In the company I work at, the PO receives a new feature to be developed. But, before writing the feature as an User Story (and later into tasks by the dev team in the refining meeting), the Business Analyst asks PO for how much time it would take to be developed to see if it is viable (cost to develop x ROI). This makes the PO to take out a dev from the team to estimate (how to be done and how much time would it take) even before refining.

It feels weird.

Who should decide if the feature is viable towards costs x ROI?

Answer 1

The stakeholders should decide if it's viable because it's their product. Ideally the BA would advise the stakeholders, but this might have been delegated to them. But that's a minor issue.

The problem is that the estimate

• Is given by a single dev
• Happens before the story is broken down into tasks

One developer may well be way off. Get a session with the most senior devs, or even the entire team, and have them break it down before you estimate anything. You can't do wholesale estimates and expect to hit deadlines reliably.

I get the vibe that you don't appreciate the BA picking the tasks, but the estimation process is the most important part of your workflow.

Answer 2

Other answers and comments focus on whether the team is likely give an accurate estimate. We should also question whether the business understands the real benefit that they may get from a feature that isn't broken down or actually designed.

It would seem better that the business should already have a backlog prioritised by highest value and should be going after things in highest value order. In which case a more indepth conversation about how each of the features at the top of the list can be delivered makes most sense.

Another thing that may be ineffective about the discribed approach is sequencing of work. If the business grooms a priorised backlog of features, and the team breaks the top ones down into enough manageable work to draw from, then the team can pull work in an order that maximum efficiency and minimizes delivery risk.

What is typical is that business don't actially do the hard work of getting agreement on what the vision is, and what the priorities are, and understand that experiment and real user feedback might be more valuable than a ”guestimate cost” matched to a ”guestimate value”.

I can imagine people who advocate the approach saying ”well, we need to know approximately whether its small or massive before we decide to do it, so this up front estimation is important”. That is an example of de-optimising the whole process to deal with outliners of ”sometimes we ask for something only because we think it's quick and easy and it isn't". Well there are other ways of dealing with that then the described approach.

if we take that thinking to the logical conclusion you could get a situation with a team sitting around with low utilisation as features "didn't seem worth the effort". Yet surely it's better to keep the team at full utilisation and review the teams size and actual delivered value quarterly.

That beings us around to the true problem here. The business is using a feature by feature waterfall model. Up front cost benefit analysis is simply a flawed at any granularity in software development. What they should be doing is seeing the team as something they should be partnering with to maximise value delivery by keeping that team working optimally on the most urgent things.