Feature Analysis Spin

It used to be that you could identify the priority of a feature by using a few metrics such as user value, business value, and technical difficulty. Those are really the three biggies, and I think those days are really gone if we are going to be honest. In software development, people love things that help quantify the problems or illustrate what can be a black box of development. I do not aim to devalue the FFA, but only put it in context a little. Truthfully, I did not know that this was called an FFA until a small development shop let me know that of course, there was an acronym for that. The same development shop happened to assign a value to Business Value without Client input, so just goes to show: you can know the acronyms and sound good at the presales meeting, but when it comes to building software, all that fancy talk falls away and you better be able to deliver. Everything in context.

Anyhow, say we have two tasks, one super easy and one really difficult. For sake of illustration, we will assume the same UV and BV.

As a side note, you can apply multipliers if, for instance, there is a reason to favor BV over UV or vice versa. That is *usually* the way I do it, even if it is BV(1.2) or UV(1.1). This is often referred to as a flexibility matrix when discussed and shown as a standalone concept. It is just a way of weighting things. See a rather strange perversion of the Iron Triangle (Time, Scope, Cost) for a nice writeup on the flex matrix. That is what the cool kids call it. Flex matrix.

Hard Task (scale of 1-5 with 1 being low)

• Business Value 2
• User Value 2
• Technical Difficulty 5
  • Total of 9 (BV times UV times TD)

Easy Task (scale of 1-5 with 1 being low)

• Business Value 2
• User Value 2
• Technical Difficulty 1
  • Total of 5

So here we would have the Hard Task ranking higher in priority than the Easy Task.

Funny: what happens if we change “Difficulty” to “Ease”?

Hard Task (scale of 1-5 again, with 1 being low)

• Business Value 2
• User Value 2
• Technical Ease 1
  • Total of 5 (BV times UV times TD)

Easy Task (scale of 1-5 again, with 1 being low)

• Business Value 2
• User Value 2
• Technical Ease 5
  • Total of 9

It changes things completely. It makes our grid of values and features/tasks Agile.

What was changed was the value of effort. Low effort is valued higher with Technical Ease. You can start knocking things off your backlog quickly this way. That is, for all the tasks that exist independently and without dependencies of external factors of any sort. It also assumes that low effort means quicker execution, which is not always the case.

Constant re-evaluation during your iterations will change the values that each task has assigned. The numbers, and backlog priority, will change. Even if you are not doing Scrum, this can be used to track features or tasks within any methodology that I can think of right now aside from strict “The GANTT IS GOD” SDLCs. No offense. I once worshiped the WBS like nobody’s business and yeah, do still use them sometimes although largely in an informal setting.

That said, with the devaluing of difficult technical tasks, you do not get to pay less attention to them right away. Indeed, certain flags are thrown when something is going to be very hard technically. This is where some Agilistas (I think they like to be called that instead of Agilists) miss the boat. Discovery is important, and you know how much discovery you need when you do it. Not before. I can mention a time I had a Client who said we would need to interface with his MSSQL Server. No problem, right? Eh… this thing was not only on an old haggard machine, but was fed old data by a complex and convoluted Foxpro system. It wound up being a huge task and Foxpro was replaced. Or, a reversed scenario: I can think of a time that a Ruby on Rails front end was proposed for an Ektron CMS installation, and it looked perfectly straightforward on paper.

Thanks for your time,

Josh