Why you should Ship Little and Often


9th February 2020

So this kinda carries on from topics I have mentioned before around working on one task at a time. This time though, that task is a set of tasks broken down for an agile scrum team, working on some features.

Little by little

There are lots of sayings out there around this, “Rome wasn’t built in a day”, “slow and steady wins the race” etc. The long and short of it when it comes to working in product development is that it is far easier for development teams to focus on and ship features one at a time than in a massive bunch.

Why you should Ship Little and Often

As a key stakeholder or business owner, you want your product to be growing all the time and as fast as possible. Sprints being planned carefully, allow teams to deliver quality features in achievable chunks and timeframes.

The last thing businesses want is for the engineering team members to be overloaded due to unrealistic goals and expectations. If this happens, it will ultimately lead to burnout and worse, it could result in sickness and mental health issues.

This is why the focus on shipping one feature at a time is imperative for engineering teams. It is far more manageable from a product owner perspective to see where a team is in a sprint and it is far easier from a development perspective to do this, compared with focusing on too much and too quickly.

Preparing for the Road Ahead

Product road-maps are always going to be there, even if you magically snap your fingers and you have 10 months work complete.

There will always be areas for improvement.

So don’t shoot too far ahead, remember what road you are on now and get each bit in place step by step. Work out the most important priorities, enter your refinement sessions with the customer needs in mind and you’ll be getting ready for an awesome sprint.

The Hunger Factor

When you haven’t eaten for hours and you find yourself at a restaurant, you kind of feel like you can eat everything. But after a bit of gorging, you’ll find you’ve bitten off more than you can chew and guess what? You can’t finish!

Sometimes, this happens in dev work too, by one person or by multiple. But it’s important to recognise as a team what you can do and what you might be able to do. I am not saying make your sprint too easy for you all, I am just saying be realistic!

Go for achievable chunks. Not too small, not too big, but enough that’s challenging and achievable!

Mega Sprints

The hunger factor can be hard to avoid sometimes. So if you and your team really want to push it, you can. Just make one out of four sprints a mega sprint. Just make sure to calm down for at least 3 more before you rise back up again.

That will quell the intense development hunger, keep burnout at bay, productivity high and your mental health in check!


Generally speaking, once you have your neatly lined up sprint…you should be aiming to release when the feature has been fully tested, its made its way through all necessary environments, the product team are happy and frankly, no more questions are being asked about the feature you are working on, other than…is it in prod yet?

Most importantly of all though, don’t fully move on until that feature has been released! If you’ve moved on, or some of your team members have moved on to the next feature and your current feature isn’t live, you’re jumping ahead. Stop right there and get back onto the existing feature, get it live, then move on!


To summarise remember to:

  • Line up achievable sprints
  • Ship little and often
  • Handle your hunger factor
  • Focus on the road in front of you, not the one ahead
  • Don’t move onto the next feature until the one you are working on is in production
  • Rinse and repeat

With that, you will ensure that your engineering and product teams are consistently shipping features, little and often, in achievable and manageable chunks, ready to delight your user base.

Ordinal Walker



Leave a Reply