Software development is a complex process. Anyone looking to invest in software for their company wants to know that they are investing well. However, most software development engagements of scale will take place over the course of many months or even years. How can you be sure your software team will meet your needs? We will show you how agile methodology impacts planning and budgets.

The Problem with Software Development

The obvious way to write software is to write all of it up front until it meets all the requirements. Companies release the product, and the project is ‘complete.’ For many years in the industry, programmers wrote software this way. However, this came with some problems.

If the software must be ‘complete and finalized’ before release, you cannot use it and reap the benefits it provides. And what’s worse, you may find that once you start using the tools you’ve built, they don’t work the way you imagined they would, even though everything went to plan. For example,

Imagine you were building an app that allows users to automatically create shopping lists based on recipes. You spec out all the requirements, which include the following:

1. Let users record recipes with their ingredients.
2. The ability to have a user ‘add this recipe to my shopping list.’
3. Auto-ordering these ingredients from your local grocery store.
4. Adding coupons for these ingredients.
5. Price comparisons against different stores.

You work with your software development team, they develop these features, and you release your product. You've spent your budget. You get your first several customers, but there’s little enthusiasm. People aren’t making orders as often as you expected. You begin interviewing your customers and ask, “What do you think is missing from the platform?”

The customers say, “I really wish there was a way to pick preexisting recipes and use them. I have to know the recipe already and enter it each time I want the app to figure out what ingredients to buy. It’s great after the first time—I never have to enter the same information twice. But it’s a lot of effort before I even get to the point of purchasing stuff.”

Now, you’re in trouble. You need customers to begin ordering things from the store in order to get your revenue. But customers aren’t entering in the information needed to make the orders, so they never even get that far! How could we have prevented this?

The Minimum Viable Product

Rather than waiting for your project to be 100% complete, we first plan for the "Minimum Viable Product" or MVP. An MVP is not the final product—but it is a functioning one that allows you to begin using it, marketing it, and understanding how your customers interact with it.

For the shopping list app, this could have been the minimum viable product:

1. The ability to save recipes with their ingredients.
2. The ability to have a user ‘add this recipe to my shopping list.’

With that, the product already does something useful. It may not be everything you want, but customers can use the shopping list the program generates to shop at their local store.

Sprints and Iterative Development

Every two weeks you meet and plan with the software team. You decide which feature they should focus on for the next two weeks. Developers call this two week period a ‘Sprint,’ because after planning, the developers sit down, and focus only on those features until the sprint is complete. They do not change plans after the sprint starts. At the end of the sprint, they push the latest features and changes to production.

This cadence—planning, sprinting, and releasing—allows you to balance your ever-changing needs with the focus required to build the software. Developers work best with periods of time during which they can focus on their tasks, so the two weeks ensures this. However, the sprint is only two weeks at a time, so there are plenty of opportunities to tweak planning and direction as the project moves forward and we learn more.

This process is known as ‘Iterative Development’ or ‘Scrum.’ The process is key in understanding how agile methodology impacts planning and budgets.

How Sprints Make Our Apps Thrive

The project begins, and the software team spends the first few sprints working on the MVP, only putting in the two critical features that we selected.

After the MVP goes live, the team starts to work on the next priority feature—the ability to order online. As they’re working on it, you get word back from your customers—they want preexisting recipes, and they want to share them.

As the sprint with online ordering finishes, you tell them to develop the coupon system and price comparison features later. You’ve learned you need a recipe library first. They release the ordering system, and you begin making a little money, even before all of your features are ready. Once the recipe library is finished, you make more money more consistently, even with two more features to develop!

How Scrum Impacts our Understanding of Estimates

Once we understand the sprint process, we understand that the budgets we set are limited in very specific ways. We can still get a good understanding of what our costs will be, but forming a picture of the ‘full cost’ of a programming project is not as cut and dry as a fixed price.

The Discovery Process

When we first meet with your team, we draw up plans for your project. We learn what your goals are, and work with you to define your MVP and other needs. We begin researching and create estimates for implementation.

However, by now you know that after the MVP your needs may change significantly. Sometimes, you may even find out your needs change BEFORE the MVP is complete. By trying out early demos, you might find that you come up with better ideas. Thanks to Scrum, we can then change course.

The estimates and timelines we give are based on what it would take to implement the project as we understand it in the initial planning phase. However, we prioritize getting something useful out the door first, and then giving you the flexibility to make changes. This means the final cost will not be known until we perform the work.

As your plans change, we will give you updates letting you know the expected impact of these changes on the project’s timeline. This way you can make informed decisions on what to prioritize.

How to Conceptualize Your Project’s Budget

It is best to think about your budget in terms of ‘how much each month you want to invest in improving the project, and how many months you want to spend engaged in the improvement.’ We will get the MVP out the door as quickly as possible while maintaining best practices. We will have a good idea of that initial timeline.

After that, it’s all improvements, and those improvements may be different from the ones you originally planned. The best part is that if at any point you decide you want to stop development, you will still have a working product. Because of the cycle of iterative development, after every sprint you’ll have an improved, newly released version. You will not leave empty handed even if you have to pause or stop funding the project.

Because of this, by the time you’re finished, you may have spent more or less than you originally planned and we originally estimated. However, with the freedom to stop development and still have a working product, you need not worry about overspending. And with the ability to add changes as you go, you can have confidence that you can adapt to your business’s ever-changing needs.