How to Decide Budget on an Agile Project?

Recently, I was asked these two questions by an Agile enthusiast who works with a services organization and have recently started practicing Scrum.

How do I know the budget without having to analyze all the features, especially when the feature list is too long and can’t fit in a sprint of 2 weeks?

The answer I gave was well received. Not because it was right from the process perspective but it was effective from the business perspective.

My simple point was: Who would disagree with the fact that processes and frameworks are created to serve the businesses and not otherwise?

Read on for the answers.

There is no way to know the budget without analyzing all the features. If the project is big and feature list is long then it gets even more challenging.

How to Deal With the Budget Problem When the Project is Big and Feature List is Long

  1. Analyze all your features
  2. Estimate the project as you’d normally do (using any conventional, non-agile methods that you’re comfortable with)
  3. Calculate one-month time-boxed cost of iteration. Refer to this excellent article by Jesse Fewell on the subject: How to Calculate Budgets for Agile Teams (Disclaimer: My entry in agile world is thanks to Jesse so I might be biased but his words of wisdom are way beyond any biases. Any Agile practitioner would vouch for his contribution in the world of Agile Software Development.)
  4. Now you have calculated your budget using two different methods. Use a variable factor to deal with uncertainty, that will come up
  5. This way you’d know how much margin you’re going to keep – now, you can make an offer that makes the business sense to your service company

When we execute a project using Scrum, the opportunity is to retrospect at the end of each sprint and ask ourselves:

  • Are we going in the right direction?
  • Did whatever we do in the past sprint is of any value from the business perspective?
  • … and take corrective actions.

In theory, taking corrective actions means that you can stop developing further or pivot if the business value is not found in the delivered increment. Practically, many people (and companies) fear that practice. Which is normal because in business we need predictability although we know that life itself is not predictable. It’s agile!

So, business-people want predictability and budget is one such practical problem so rather than dealing with that problem using agile techniques, we can choose to deal with it using any technique that works.

Sure, since we’re considering Agile, we’d get the cost of iteration and add a variable factor to make some changes but it is, at its best, a kind of guesstimation.

This is not a perfect way. This is not where you will get optimum value from Scrum. Scrum framework is effective when the focus is on delivering value, not on finishing something by the budget.

If you can, avoid Scrum – or other agile practices – for these kinds of projects. If not, then you can tweak but in that case you’re not using Scrum – or agile.

Also in some cases, the clients of a service provider company would not much care which development framework the service provider uses. All what matters to them is how you will deliver the value. So make an offer to them that they cannot refuse.

  • Is this Scrum? No.
  • Is this Agile? No.
  • Is this business? You know it better 🙂

In my opinion, when not to use Scrum is a distinction that every practitioner must have because then Scrum remains a tool, not a magic wand.

The war has to be won; does it matter if you win it using Swords or Guns?

Scrum Teams and The “F” Word

What’s the “F” word in Scrum?

Not [F]un. Not [F]ire. Not [F]ailure.

What is it?

Most scrum teams deal with software engineers so they are concerned more about engineering challenges than anything else in all what they do.

In Daily Scrums. In Review Meetings. In Retrospectives.

Often, they don’t pay active attention to important “F” word.

Scrum Teams and The F word

Don’t get surprised when I say that the “F” word is their “FEELINGS!”

Don’t get surprised.

Techie guys don’t tend to speak more about their feelings. Essentially, they are left brainers so they seek logic in what they do. Feelings come as a second thought to most.

But what they feel while being a part of Scrum team is important for a Scrum team to succeed.

“People who feel good about themselves produce good results”

~ Ken Blanchard, Spencer Johnson, The One Minute Manager

(Read more about my experience with The One Minute Management Learning)

Cannot agree more: People who do not feel good about their work, cannot produce good results!

And, Scrum – or any other Agile framework for that matter – exist to produce great results; not for any other objectives.

Scrum Masters need to figure out ways to understand the feelings part of their team members and create situations where the team is motivated to assume the ownership of the tasks they undertake.

So, ask your team member directly how she feels if you have a great rapport with her. If not yet, there are other ways figure that out. Some example questions:

1. What excites you to do X, Y and Z?
2. What situations make your low point?
3. What situations make your high point?
4. How did you find working with other team mates on this sprint?
…and so on.

Choose the questions that open up your team members and share their experiences.

Experiences express feelings.

Understand what makes them feel good; what makes them feel uncomfortable and create situations that are motivating for the team members to perform.

A small but important soft skill that every ScrumMaster should have.