Progression post its

Challenges of SCRUM — Increment vs Progress

By Gonzalo Amuchástegui Mayoral


For the past years we’ve been seeing some scary statistics. In late 2020, BCG estimated that 70% of digital transformation projects didn’t meet desired outcomes.

Most software projects fail. Why? There’s a variety of reasons but between these, I can mention:

  • Lack of transparency regarding the real progress and status of the project.
  • Expectations not aligned between the owners of the project and the development team
  • Teams with no clear strategy and focus
  • Launching a product that was not the product users wanted or needed
  • And so on…

The agile manifesto has 4 values.

Among these, there’s the value of having working software over comprehensive documentation. This relates to the fact of having features in market fast, in order to test them, learn and improve instead of spending months working on documenting what you will do.

We need to know where we want to go. We have to plan short iterations, define what we want the team to deliver in such iteration (or after certain iterations), test with users, learn and continue developing with more and better information.

To achieve this, it’s key to deliver functionalities that can be tested.

What does usually happen?

It’s really common for teams to work, and after a period of time, to show “progress”, and describe the situation as if everything is OK and as planned. Product owners, project managers or product managers just review that progress, and believe they are in the right path and closer to launch the product into the market.

Once the release date is getting near, let’s say 1 month before, the Product Owner asks the team to start closing up and testing in order to be sure everything is working as expected. That is the moment where they face a serious problem: progress does not mean nothing itself. When they want to close 100% the different functionalities, many things that were not contemplated previously start arising.

Teams have a hard time understanding which is the real progress and status of the project they are working on. Generally, when they are asked how much they’ve progressed, they answer with % which are based only on perceptions or feelings.

Why does this happen?

On the one hand, because we don’t really know how much is pending or how far we are from the goal (basically the team’s expectations are not aligned with the client’s expectations). A clear cause of this problem is the lack of definition of the different functionalities at the moment of their execution. As consequence, we end up having teams delivering products of poor quality and teams working more hours than expected, all just to deliver what was promised. In other words, dissatisfaction for all.

On the other hand, because teams do not have a clear focus and do not work in short iterations. One of the goals of agile teams is being able to test and learn from what is done each sprint (iteration of 1–4 weeks). The team should be capable of launching something that works and adds value to users; and of course improves our product.

How to SCRUM?

If we want to have a product that is “launchable” once the sprint is concluded, it’s necessary to focus, to avoid working in 10 things at a time, and to, as a team, have a mindset of closing functionalities (with the correct prioritization). It is much better to have 1 functionality finished, that will allow us to test the product with users, than having 3 in “progress”.

The issue with progress is that it is hard to really understand when the functionality is finished. This is handled with the acceptance criteria.

As a challenge, SCRUM teams need to have the “increment” mindset and work in order to achieve it sprint after sprint. Finish and close up things, not starting over finishing.

It is really common to start many things, but not so common to finish them. To avoid this, SCRUM relies on Dailies (15 minute meetings for teams to know what each of the members is working on), and on Kanban boards (To Do, Doing, Done) which each team adjusts according to their needs and preferences.

Let’s imagine we are the owners of the product. We manage to achieve the first version, and then start learning from users and continue adding functionalities. To keep on learning, it’s necessary to add value to the product, that is to say, add new functionalities (or certain changes).

Once a sprint is concluded, the development team wants to show us how much they progressed. That is when I ask them: “Can we upload them?”, to which they answer they can’t, because there are some details missing. Therefore, none of the functionalities were really completed, there’s no increment. I can imagine the feeling (and even some memories) of what this causes.

To conclude

¿What’s the point of progressing in many things at a time? ¿Isn’t it better to focus on finishing (as a team) one thing at a time, and be able to have certain functionalities ready to launch once the sprint is finished, in order to build and grow our product, and keep on learning?

It’s usual to lose focus, over commit, and do many things at the same time. A SCRUM team, through the different ceremonies that the framework suggests, seeks transparency and communication.

Both Scrum and Kanban encourage the mindset of finishing things over starting new ones. Scrum refers to it through one of it’s artifacts: increment — it’s the sprint focus: being able to deliver value at the end of each sprint. On the other side, Kanban does it with WIP (work in progress); which suggests this to be as small as possible, and to avoid starting something new before completing whatever is in progress.

It is key to fully incorporate this mindset in the team and understand it will take many retrospectives to achieve it. Through these, the team will, iteration after iteration, continuously improve, learn, and build quality products adding more value to our users.


By Gonzalo Amuchástegui Mayoral


If you have an idea or are working on a project you could use some help with, feel free to contact us! We’d be happy to help you… or who knows? Maybe be your new partner in crime.

You enjoyed this post and want to read more?


Subscribe to our monthly newsletter! 📬

* indicates required

1187 750 Amalgama

What you’ll get

  • A prototype of the product to be built reflecting the product’s vision.
  • The roadmap for development.

What we’ll be
working on

  • Business Analysis and Planning
  • Market and audience analysis
  • Users analysis: interviews & surveys
  • Value proposition analysis & definition
  • Prototyping
  • User testings
  • Roadmap definition

What you’ll get:

Obviously, what you came for!
An amazing, cool, trendy, app web
or any kind of digital product.

What we’ll be working on:

  • Product Research & Strategy
  • Marketing & Growth strategy
  • Frontend and backend development
  • UX/UI Design, Research & testing
  • QA & QC
  • Naming & Branding

What you’ll get:

An appealing and unique website with smooth usability that your audience will love to engage with.

What we’ll be

working on:

  • Brand analysis and goals definition
  • Wireframing
  • Look & Feel application
  • Web Development

Swish 365

Swish’s founders came to us to build an app so that parents could book their children’s basketball sessions in a simple and fast way. Together we developed a mobile app and web app that also allows them to have visibility on the progress and results of their children.

Services offered
Product Discovery
Product Development

Mobile app for IOS and
Android App + Web App

iOS App
Android App


Privacy Preferences

When you visit our website, it may store information through your browser from specific services, usually in the form of cookies. Here you can change your Privacy preferences. It is worth noting that blocking some types of cookies may impact your experience on our website and the services we are able to offer.

For performance and security reasons we use Cloudflare
Our website uses cookies, mainly from 3rd party services. Define your Privacy Preferences and/or agree to our use of cookies.