Agile Funding – A new approach

Agile funding is an underestimated part of agile. Many Agilists don’t think you should or even can estimate the cost for developing a product. But if you don't know how much its going to cost, how will you know if you can afford to create the product or even a semi reasonable MVP of the product.  Often its limited to working out the cost of an agile team over a sprint and then using that as the basis for the funding. This is just time and material and doesn't really tell you the total overall cost. This is just like when you ask for a quote from an electrician to change all the lights in your home to downlights. If they just give you a quote with only their labour, you’ll both end up most likely confused and upset and then realise someone will need to pay for the actual downlights.

As a Scrum Master I love working on Time and Material (T&M) projects - No pressure. Just build sprint by sprint until the product is suitable. There are many dangers with building a product using a pure T&M approach – will you be able to keep a team going until the product is ready for use; will you be able to afford to keep it operating once you have completed it or at least an MVP. Is your business sponsor happy to continue to inject funding indefinitely? Even more importantly - just when will you get to use the product - 6 months, a year or maybe never. 

So when starting a product or project off you really need to know how much its going to cost. How much is it going to cost you to develop, how big a team will you need, how much is it going to cost to keep the product operating and growing? 

So how do you calculate the cost for creating a product / project? 

Almost every Project Manager have their own set of spreadsheets to assist them in working out the funding required. It’s a pity they are all different and often the final cost depends on the Project Mangers experience and a lot of luck. Whenever a sponsor or product manager ask’s for a quote to develop their product, often its experience that is used to determine the cost, effort and duration of the work. Was there a project in the past that was similar? (Or as they say - Practice makes perfect..??)  

Or maybe we can just run over time or just keep spending – its only money right ??  

There must be a better, consistent and more accurate way to quote a product so that you KNOW and be confident in what it will cost and when you can expect to have it.

The Agile Quotation Tool (AQT) was developed to help provide a consistent and accurate approach to providing you with your quotes harnessing your experience and knowledge. It also assists with suggesting other cost considerations that you haven’t thought of or may have forgotten.

It involves determining what needs to be built. Highlighting the features of the product, what needs to be done to build those features, how is it to be built (the proposed solution), what are the labour costs (the agile team or multiple teams), and how much will it cost to keep operating the product once it exists.

The Agile Quotation Tool is used during an Agile Quotation session. During the session you get the following:

An overview of the product, including what is in-scope and what is out-of-scope

Estimate and Prioritise features. This can be as detailed as you need, but the more detail you provide, the better the quote will be, and the more confident you'll be with your investment. AQT allows that flexibility where you can remove or de-prioritise features if the cost estimate gets too high.

Determine the most likely and viable solution, at a high level – how are you going to build the features. The developers can also estimate the effort needed to build each feature and if extra work is needed, such as building in enablers. i.e. Include Automated test framework.

Determine the agile team(s) structure and the number of teams needed to deliver to the plan.

Play with the features, number of teams, or team sizes so that you can juggle costs, and timeframes. 

So give it a go and sign up for a free trial

How do you make sure you have covered off all of the critical requirements?

How do you make sure you have covered all off all the critical requirements?

How often have you heard someone say – “We missed that requirement. It was just an oversight” or “It’s obvious that requirement should have been included.”

Using agile doesn’t mean that you shouldn’t spend time building a quality initial product backlog. You are still able to change the backlog as needed as you proceed with the product development. But a quality backlog helps planning for the product releases and working out what you want the product to achieve.

So, what are the techniques that can be used to make sure you’re not missing critical requirements / features?

There are a number of different techniques that can be used such as:

·       Story Mapping

·       Impact Mapping

Story Mapping

Story Mapping is a technique to take the vision and high-level goals and turn them into a 3-dimensional map of the features. It provides a story for the product and gives a product development strategy for the product. The features / stories are listed in order of importance and allows you to break them into releases.

Refine the map by:

       ·       Breaking the Features / Epics into smaller stories. This can be done via story splitting techniques

       ·       Add in new cool, new product ideas that are out of the box

       ·       Think about possible variations that users may want from the product

       ·       Think about where the product could go wrong and how to recover from these problems

       ·       Are there any other potential users that haven’t been covered yet, that would use the product differently?

Now:

·      Show the map and collect feedback

·       Get technical feedback and add in the enablers and dependencies / constraints

·       Finally group into releases that make sense

Impact Mapping

Impact Mapping is a strategic planning technique that can be used to provide a clear vision for the product. It provides measurable scenarios that help build out the key activities / goals and their impacts.

Always begin with a WHY

WHY – Why is this product needed? (To make money is not a valid reason)

WHO – Who benefits from this product?

HOW - How does the product impact this person?

WHAT – What does the product deliver?  

After answering the above questions, develop an Impact Map.

1.       Write out a goal

2.       Work out how you will measure the success of the goal

3.       Who are the actors? eg customers

4.       How will they be impacted – way’s that we can achieve the goal

5.       What deliverable is needed achieve this impact

6.       How can we measure deliverables are successful?

See the example below.

Remember that all of these techniques take effort but the outcome is worth the effort!

How do you Estimate

So how do you estimate requirements; it doesn’t matter if they are written as User Stories or features or even use cases. The problem is not the mechanics of the process, rather it’s the actual estimate.

How many of you have sat in a Estimation meeting or Sprint Planning meeting where you have been asked to play Planning Poker and estimate the story points of a User Story?

The whole team needs to participate – after all it’s a team sport, so you can’t get out of it.

The first question asked by the newbies is - What’s a Story Point worth, is it a days’ worth of effort?

I have heard lots of answers to this question from a simple

”” Yes you can think of it that way “” – Oops ??

“”It’s the complexity of the story”” – What does that mean ?!?!

So you all go over the story / feature and ask questions so that you understand it better. Actually, if you’re like me, you start to build a solution in your mind about how you are going to solve the story. Then you convert it into effort.

 Is this the right way to estimate? Actually, I don’t think so.

Story Points are not viewed in Person Days. They do relate back to complexity and using the team’s velocity you are able to measure how that relates to how many story points in a sprint.

So in the end it does relate back to effort.

But initially it all starts with complexity.

So what can help you estimate the complexity??

You can use the Affinity Grouping. This is a fast way to estimate multiple stories / features. Simply group stories / features together that are roughly the same size.

1.     Draw up columns for the relative sizes - small, medium, large, extra-large. The basic Tee Shirt sizes.

2.     Select the first story and discuss as a team if it’s a small, medium, large, extra-large.

3.     Place into the correct column.

For all the other stories, its now just a relative comparison. Is it the same, smaller, larger? If necessary, just add a new column – Extra Small, Extra Extra Large.

You can then convert from Tee Shirt size to Story Points – Small = 1; Medium = 5; 2XL = 34 …

Of course, the trick is determining the complexity for each story or feature. It’s a given that the smaller the size of the story / feature the easier it is to estimate the complexity. It’s a given that you would be more accurate estimating building a window compared to building a house.

So story / feature splitting is very useful when you know the story is too large and you are unsure of the size. After all what is the difference between a 2XL and a 3XL feature. Actually, the difference can be Huge.

Remember not to split by technology stack. Ask as you split the story, how are we going to show that the story is complete.

There are also other factors you can include when determining the complexity:

Feature Categorization – the type of feature being built

• Basic Feature - Is this a basic feature that has been done by everyone – it doesn’t mean that its simple or easy to build, but all the risks have probably been worked out and you’re not learning as you go. This should be easy to estimate.   
  
• Performance Capability – Is this feature / story cutting edge and relatively new? Again, there is some risk, but it’s not completely strange and the risk is manageable. The estimate will need some contingency as its not cookie cutter work.
• Excitement Capability – Is the feature / story brand new and hopefully never thought of before? Its something that you will need to put effort into, to design and get correct.

 The actual Complexity

·         Obvious – this is well known, and you just need to follow a well-worn path or best practice.  

·         Complicated – This is still known and it’s a matter of following good practice and analyse thoroughly. Just need to determine some things or bad things will happen.

·         Complex – There are lots of unknowns which need careful analysis and planning. It’s really all new and will need some probing (spikes) to work out the approach.  

·         Chaos – Absolutely new and unknown. All you can do is organize a series of spikes or experiments to learn what seems to work. This is almost unable to be estimated and should be really be broken up into the Spikes & experiments which are time limited.   

All these approaches help in determining the complexity score – story points for the features and stories. The more effort spent on the estimation improves not only the estimate, but also the teams understanding of what is being asked of them.

It’s well known that each team will come up with slightly different estimates, but as this is a team sport, the estimates usually don’t vary too much especially if you have a consistent approach.

Of course, their estimates on what they can achieve will get more accurate as they compare what can actually be done against what they thought could be done. This is experience and an experienced team will estimate better that a team which is just starting off.

 This is the empirical approach and as they say – practice make perfect!