Updated: January 30, 2023

Choosing a Software Development Model: Predictability vs. Velocity

Choosing a Software Development Model: Predictability vs. Velocity

Deciding on a software development model is one of the most critical and challenging decisions a company makes. New projects have such potential, and many project managers fear to squander that potential by choosing the wrong model to develop the software.

We're going to cover how to choose the right software model for your project. But first, let’s review what a software development model is and what the options are.

Software Development Model Options

A software development model is the set of processes and procedures that govern the development of a software project. It’s your “modus operandi”, so to speak.

All software models balance two factors: predictability and velocity. You can precisely know what you’re building but build it slower (predictability), or build fast and change as you go (velocity). There is no right answer, only the right solution for the specific project.

What Is the Velocity Model?

To understand the velocity model, think of a puzzle. A model favoring velocity tears open the box, throws it away, and starts putting the pieces together, not knowing what the completed puzzle is. You try different combinations until you find something that fits. The picture is built gradually over time. And no one knows what form it will take when it’s done.

Agile methods such as Scrum or Kanban exemplify the velocity side of the equation. They focus on iterating quickly and working closely with product owners to move toward the finished product. You don’t know what the result will look like, only that it will satisfy the needs of the business as defined by the product owner.

Pros and Cons of the Velocity model

There are plenty of pros to an approach based on velocity, such as an Agile methodology. First, it gives you the ability to see a working piece of software right away, and you’ll be able to bring your product to market more quickly. You know the business outcome you’re trying to achieve, but the team decides how to make it.

However, the primary drawback, or con, is that steadily building new granular services without strong architectural oversight and design can lead to messy systems. They become difficult to manage because of emergent properties and interdependencies, and they become more expensive and less flexible than a single application would be. Segment wrote a brilliant article about why they went back to a monolithic application from microservices. So, if the product owner and development team don’t work together closely under the velocity approach, the principle of emergence states that they’ll likely end up with a ball of string that is more complex than an upfront design would have been. The shorter planning horizon exposes you to a risk of rework.

Planning with a Known Velocity

The velocity model is flexible, but that doesn’t mean it involves no planning whatsoever. When a development team has been working together consistently—and particularly when they have a few sprints from a current velocity-based project under their belts—they can measure with fairly high accuracy how long each slice of the project will take. For example, they may be able to say, “This team tends to deliver fifteen to twenty story points per two-week sprint.” (Note that it’s not total precision we’re looking for in these estimates; when you’re working with velocity, a ballpark is enough.)

Long-Term Planning with Velocity

“Story points per sprint” is a metric the development team can use to extrapolate into long-term planning, identifying roughly how much time larger segments of the project—or even the project as a whole—might require. For example, if they’re working at a rate of twenty story points per two-week sprint, then they know that, over the next six weeks, they’re likely to be able to complete about sixty points. With that in mind, they can work with the project owner, client, and any other key team member to identify the most important story points they should be focusing on during that six-week period.

What Is the Predictability Model?

To introduce the predictability model, let’s go back to that puzzle. A predictable development model is carefully looking at the picture on the front of the box before putting it together. If you run into a rough spot, you recheck it to help guide you along the way.

The ever-present waterfall model is an example of a predictable development model. The project progresses through clear stages, with each step ending before the next begins. You decide all requirements before development begins. The developers build based on a solid plan that doesn’t change quickly. Then testing happens all at once, followed by the release of the software.

Waterfall can include testing loops and iterations. A large project can be broken into smaller pieces that each follow the waterfall process, for example. Still, waterfall is generally prescriptive up front, not starting until a large amount of information is known about the project.

Pros and Cons of the Predictability Model

On the pro side, the predictable software development model allows the project team to see the entire picture of the end product before beginning development. You’ll always have the image on the front of the puzzle box to tell you where the pieces fit, and you’ll be able to fully optimize the design before building, making the building phase more straightforward.

The biggest con on of this model is that you’ll be sacrificing velocity since it will take longer to build a complete picture of the project upfront.

The Software Development Model Decision Tree

So, you may ask, which model is better: predictability or velocity?

We don’t universally prefer either, because we know the needs of the project will decide the most beneficial way to build the software. There are three factors to consider when choosing which one is best for your project:

  1. Risk Tolerance

    The first factor to consider is the risk tolerance of the software. The company’s risk tolerance comes into play, but even within ne company, different pieces of software carry more risk if they malfunction.

    The core software application that manages day trading for a bank has to work according to precise specifications and according to applicable laws and regulations. A predictable approach works well to mitigate the risk of such an application by allowing the development team to optimize the application design while ensuring compliance.

    A medical device is another example. If a malfunction could cause a life-threatening situation, the predictable approach will ensure proper levels of scrutiny and testing before the machines are made available. This “cost of error” should be considered when deciding your development model.

    Small business applications and services that often front more complex pieces of software are better choices for the velocity model. The organization should build the service well, but a malfunction doesn’t cause a massive financial impact on the company. A focus on velocity makes sense in this scenario so the team can iterate and gather feedback to create a satisfying user experience.

  2. Budget

    The second factor in choosing a development model is the budget of the project. How much is the company willing to spend to build the software? The predictable model tends to be more expensive than one that emphasizes speed. It is more challenging to create an expanded breakdown and full picture of the project ahead of time. The extra effort and cost mean that a predictable model requires deeper pockets.

    In the short term, velocity-based models will save you money. You’ll build in small increments and use feedback from users to iterate and improve on existing traits. Every sprint ends with usable software, so if money is tight, you’ll still have software that provides value, even if it doesn’t have all of the bells and whistles.

    I said that velocity-based models save money in the short term for a reason. Because of the nebulous nature of velocity-based projects, they can go on indefinitely. A poor design increases the risk of rework and may cause the team to re-architect and rebuild the software down the line. These events could end up making the project more expensive in the long run when compared to predictable models. There is a lower cost per unit of value, but there is a higher cost spread over years of development.

    The budget and risk tolerance work together to help decide on a software development model. When you pay for a software project is called a budget. When you pay your insurance company, you name it a premium. These two things are the same. You’ll pay a premium for predictable models because you’re insuring against future risk (and offloading that risk to your software development consultant).

    On the other hand, velocity-based models produce a faster result and can be cheaper in the short-term. However, you’ll be taking on a lot of the risk as a collaboration between the client and consultant is the linchpin. Communication breakdowns lead to software breakdowns.

  3. Time

    The third factor in choosing a development model is time. How quickly does a working piece of software need to be released? There may be market forces or other factors that drive you toward delivering a piece of software as quickly as possible.

    The velocity model is the best choice when you need to beat a competitor to market. Apple has built an empire from delivering first to the market and then improving their devices over time. Agile models thrive when you can provide the first version, gather feedback, and then improve. It allows you to build a solid customer base and gain the first mover’s advantage.

    When time isn’t a factor, a more predictable model will help to deliver a complete piece of software. And you can have checkpoints along the way to help ensure you’re on the right path. When we use a predictable model, we use the incremental build model, which allows for functional prototyping during the process. You can put to rest nightmares of waiting a year to see a piece of software that doesn’t do what you want it to do.

The three factors are risk tolerance, budget, and time. All three elements must be considered carefully before deciding on a development model.

Difference between Predictability and Velocity: A Recap

Velocity-based approaches lead to more uncertainty. You won’t know what you’re building until you build it. You’ll bring it to market faster, but you’ll always be tweaking and changing it. While some preliminary architectural design is necessary in all models, velocity-based models tend to favor rapid progress and embrace change. On the other hand, a slower, more predictable approach takes longer to implement but comes with less chance for scope creep or costly “redos” and changes because it’s been fully designed and optimized in advance.

No Matter What Model You Choose, You Can Succeed

Both predictable and speedy software development models can deliver valuable software. The tech industry and corporate worlds tend to latch on to the latest trend and try to make every project fit into a mold, whether it’s a proper fit or not.

We don’t believe in placing square pegs in round holes. Software development isn’t about the “right” or “wrong” way of completing a project. There is only the right way for the project in question.

On your next project, try to weigh your risk tolerance for the software, the budget constraints, and the time-to-market requirements carefully before choosing a model. If you still aren’t sure, contact us, and we’ll be glad to help you decide which model fits your requirements.

Publication date: February 3, 2020
  • outsourcing
  • software development

Learn more about how Syberry can help your business achieve its every goal

What our customers say about us

Syberry’s team was highly responsive and communicative, managing our project smoothly, responding immediately to any issues that arose, and delivering great software at a reasonable price.

Richard Harkness


Elk Grove, CA

How we help ADEPT Driver Company

We developed a web-based driving simulator for teens and another for adults. The products run on Chromebooks, and the team added features that enable them to measure a driver's ability to avoid a crash.

Technologies used

I don't think you could find a better company to manage and build your project. I get so many compliments on my application, and it has a lot of unique and complex development.

Todd Surber


Charleston, South Carolina

How we help PIXRIT Company

A photographer approached us to build a web-based software platform that combines the fastest social media manager with state-of-the-art galleries and provides the ultimate tool for photographers to upload, store, back up, and share their photos and manage their SMM activities.

Technologies used

The high-quality, user-friendly software Syberry created for us has helped grow our clientele, and we were very pleased with their partnership. Syberry was straightforward and consistent in their communication, met every deadline, and ensured a hassle-free development process.

Vince Hughes

Owner, Steel Estimating Solutions

Knoxville, TN

How we help Steel Estimating Solutions Company

Our client was inspired to create a product that helps steel erection companies perform faster, more efficient estimations and bids. We developed original proprietary software from the initial concept.

Technologies used

Syberry delivered world-class service for a cost-efficient price. They communicated well with our team throughout the process, breaking down steps and utilizing a streamlined management system to keep everyone in the loop at all times. The resulting new platform far outperforms its predecessor and has received rave reviews.

Bill Fahy

Owner, FDI Creative Services

Houston, TX

How we help FDI Creative Services Company

Following strict regulations and requirements, we used AWS to develop a custom e-commerce web app that includes shipping integration. Since the site’s launch, the team has continued to make updates.

Technologies used

The application was delivered on time and within budget. Syberry explained their process thoroughly and accommodated to scope changes effortlessly. Their stellar project management, highly responsive communication, and proactive attitude set them apart.

Ricardo Casas

CEO, Fahrenheit Marketing

Austin, TX

How we help Fahrenheit Marketing Company

We developed a large, complex .NET application with various third-party integrations. The team built the software from scratch based on existing wireframes.

Technologies used

The end solution exceeded the client’s expectations. Syberry delivered high-quality products on time and at outstanding value. They provided frequent updates and repeatedly sought feedback at each stage. Customers can expect a highly experienced team that easily translates concepts into solutions.

Rudy Milkovic

Executive Director, Velikom

Austin, TX

How we help Velikom Company

Our team built video streaming software as a web and desktop app for a third-party client. We completed end-to-end development—from scoping to feedback cycles to QA—using PHP and Wowza Streaming Engine.

Technologies used

Syberry has significantly improved our existing platform, and they continue demonstrate their dedication to our business goals and needs by making thoughtful suggestions for enhancements. The Syberry team is communicative and reliable, mitigating all our concerns about outsourcing software development.

Cory Kowal

VP of Products, THG Energy Solutions

Tulsa, OK

How we help THG Energy Solutions Company

Taking over for another vendor, we served as the ongoing software engineering partner for an energy company’s cloud-based platform. The company provided scoping, development, testing, and deployment services.

Technologies used

Syberry has been an invaluable partner in development. Their impressive team was more than able to fulfill our project needs, and their expertise and dedication led to smooth collaboration every step of the way. The result was a successfully launched product that has received lots of positive feedback.

Chris Cox

CTO, MyMelo

Louisville, Kentucky

How we help MyMelo Company

We provided staff augmentation resources for a development project. The team contributed engineers to follow an established roadmap to perform updates and add features.

Technologies used

The database Syberry developed has empowered 40 organizations to help in the fight against COVID-19. A communicative partner, the Syberry team worked quickly and efficiently to launch the website, and they continue to invest their time and efforts into the project.

David Snyder

Product Director, Covid Resource Network

West Orange, New Jersey

How we help Covid Resource Network Company

The company developed a website that serves as a database where organizations can find and donate to other organizations. Currently, the team is working on enhancing the website and fixing bugs.

Technologies used

Syberry was a patient partner, making this engagement feel like a true collaboration. The system they created for us will save our team significant time and frustration.

Joyce Cubio

VP of Operations, Ernie's Mobile Home Transport

Yuba, California

How we help Ernie's Mobile Home Transport Company

The team built an information hub for a mobile home transport and permit service. After discussing the existing system and processes, we delivered a new structure for forms and data.

Technologies used

The Syberry team is skilled at juggling multiple projects. Though they are in high demand, we were confident that they had the resources and the expertise needed to focus on our partnership. Their constant dedication led to a truly successful engagement, and the final product exceeded all our expectations.

John Fox

Executive VP, Fox Business Automation Solutions

Lakeland, Florida

How we help Fox Business Automation Solutions Company

Brought on as a third party, we supplied ongoing development services. The team work on multiple projects and deliver according to predetermined design specifications.

Technologies used

Contact us to learn more about how Syberry can help your business achieve its every goal!

0 / 2500

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Submit loading...

Was this page helpful?