AUTHOR: Joao Ferreira

As you probably know Scrum is a methodology that enables teams to self-organise and iteratively deliver value.

Today I am not writing about how to successfully implement Scrum, my focus is on what it looks like when you have achieved it.

A successful Scrum Team has the following characteristics:

  • You have a DEEP backlog (see below) and a process in place to keep it like that;
  • The team is comfortable with what is asked of them and ok pushing back when needed;
  • The team is delivering consistently and what is delivered provides value;
  • The team is active during the rituals and understands their purpose;
  • Velocity is predictable and you are not obsessed about it;
  • Stakeholders understand the iterative process and provide feedback at the right time;
  • Finally, the team is having fun.

DEEP Backlog

A DEEP backlog is one that is, Described appropriately, Estimated, Emergent and Prioritised.

A bit of pragmatism is welcome here.  Does every single item need to be estimated?  Maybe not.  What does described appropriately mean?  Do all the stories need Acceptance Criteria and a “proper” user story construct?  Probably not, but most should.

There is a balance in all the above points.  If the backlog helps the team deliver value, it helps the Product Owner plan and adapt, and it takes in and feeds back to a story map or roadmap: then you are in good shape.

Comfortable team

A comfortable team is one that is aware of their capacity and limitations.  It’s a team that has a good dynamic about it, and it understands what is being built, but is also not scared to push back and debate the different directions.  It’s a team that knows its comfort zone and is willing to come out of it and improve.

Most of these things are acquired over time so it’s very important not to be swapping and changing team members very often.

Consistent Delivery

You should be delivering value in each iteration – if after every Sprint you can see that what you are building is better than in the previous iteration, then you know you are onto something.

It’s good to have sprint goals and you should try to smash them every sprint, I just don’t believe in getting too hung up on them.  In one Sprint you might not deliver everything and in the next one you deliver a bit more.

But if you are delivering consistently 90 to 110% you are doing great.


Scrum has specific rituals that happen at specific times.  There is the daily stand up happening every day.  The retrospective, planning and review/demo happen once every sprint, and there is the backlog grooming session that depends on the state of the backlog but at least once every sprint.

If your team is actively participating in all these rituals and understands the value of each of them you are doing well – you might be doing extremely well and adapt the rituals to suit your team and that’s fine too.


As metrics go, Velocity is probably one of the most important – without velocity it’s very hard to plan ahead or know when the project will be finished.  While it is imperative that you know your velocity and should look to improve it, you shouldn’t obsess about it.  It’s better if you look at it as a fuzzy metric and not get depressed if in a Sprint it goes down.

The team should not stress too much about getting a better velocity, or you can get into all kinds of issues (like the team padding estimates just to get more points).  While Velocity is super important for planning, at the end of the day you are not delivering points, you are delivering software.

Rushing software is never a good idea.


In this context, stakeholders are all the people that are external to the team (most often the people who are paying for the software).

If your stakeholders are happy with the process and understand the fact that new items need to be analysed before dropping them with a team member, that value is created iteratively, that the product backlog is a living artefact that is supposed to evolve, that estimates and plans can and will most definitely change over time, and that feedback and communication are King, then you are in a good place.

If you are not there, then you should work with them to get there.


Fun might seem like a weird one to put in this list, but the truth is that in any kind of job if you are miserable,  you will not perform well.  If your team members are not happy then their productivity will be lower, and if nothing is done to improve things they will probably leave.  All the knowledge they accumulated will be wasted and you will have to find a new person to fill their job.

It is important to have a relaxed environment where challenges can be discussed, where people feel appreciated and where they can laugh together while changing the world.

If you have all the above, well done you!  If you are still getting there, that’s ok – Rome was not built in a day.

Keep experimenting and looking for ways to get there, and take special attention to the retrospectives.  Follow the book but experiment with new things also.

Eventually you will get there, and when you do, you will be achieving amazing things as a highly productive team and you will be part of a successful Scrum implementation.

Sign up to our newsletter

Keep up-to-date with more news and views from our contributors by subscribing to our monthly newsletter.

Who contributed to this article

  • Joao Ferreira
    Principal Business Analyst

    Joao Ferreira is BlackCat’s principle business analyst. He acts as a vital link between process owners, endusers and development teams, helping customers define product visions which deliver business value. Joao’s background is in development but over the past decade he has taken on increasingly strategic technical roles, including a number of years as a product owner for a leading technology company. Joao has a degree from the Santarem School of Management and Technology, is a certified Scrum Product Owner and an accredited member of the Chartered Institute of IT.