3

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?

  • 1
    Are you working with Scrum? The idea of there being a PO suggests it, but you're not saying it. – Erik Nov 30 '18 at 13:56
  • 1
    @Erik I'd say Kanban cause they're estimating time instead of complexity. But of course saying you're doing Agile is like saying you like the color Color, so, all bets are off. – rath Nov 30 '18 at 14:02
  • 6
    Typical issue : Business wants estimates to see if they're going to do it, IT wants briefing in order to do estimates, and Business don't want to invest money into a briefing if they're not going to do it. Just do ballpark estimates and let business decide, anyway they will do what they want... – Laurent S. Nov 30 '18 at 14:31
  • You used the words "limited by" in the title. Why do you see this as a limitation? – dwizum Nov 30 '18 at 14:40
  • @Erik This team I'm working on is new to agile methodology. We want to try Lean with kanban board. I used "limited by" because this particular feature is seen as an improvement I suggested, it's not a necessity. Maybe this feature won't be accepted by Business Analyst because it doesn't show us a proper ROI. – FrancoBits Nov 30 '18 at 15:46
3

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.

| improve this answer | |
  • Hey @rath, thanks for your comment. Usually we call the software architect (technical leader / senior dev) to estimate, and I agree that estimating without breaking the feature into tasks is not the right thing to do, but at the moment the BA asks for an estimate, before the feature even enters the product backlog, the dev team is working on the current sprint. After the sprint ends, we get the next User Stories, break into tasks and estimate. Maybe we should get these features BA asks to estimate and break it down into tasks and estimate in this meeting? – FrancoBits Nov 30 '18 at 16:03
  • @FrancoBits That would be what I would push for. The BA seems to operate outside the Scrum process at the moment and it's forcing the devs to give wrong estimates, which in turn makes his viability analysis stand on shaky foundations. It's OK to give a ballpark of course but for anything substantial, breaking into tasks and estimating correctly is the way to go. – rath Nov 30 '18 at 16:32
  • @FrancoBits So you're doing Scrum... the time estimate is usually 1 Scrum. If it takes longer, the usual process is to break the task down so the team has something to show in each scrum.... again, the tasks need to be analysed and broken down. If the task is worked outside of the Scrum process, I guess the impact to the team is not as severe. But still, the BA's viability estimate is off – rath Nov 30 '18 at 16:41
0

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.

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .