#NoEstimates? Get a grip. Sprint level estimations are vital

The purist in me loves the concept of no estimates. Imagine a world where designers could just design until everything looked perfect, developers could just code until everything worked exactly the way they wanted and at the end of it all, whenever that might be, their labour of love is packaged and delivered to the happily waiting customer.

Let’s all take a moment to get realistic. The whole elitist, self righteous attitude towards the entire #NoEstimates movement needs to stop. Would you take your car in for an MOT and tell the mechanic to do whatever work needs completing to meet your goal of passing the MOT without expecting an estimate? Absolutely not. Would you call a kitchen fitting service, tell them what you want your new kitchen to look like and then let them install everything before giving you a price? Don’t be ridiculous.

I’m afraid the same is true of software development. If you think for one moment that any respectable organisation is going to give you a blank cheque and let you get on with the work, then you’re very much mistaken. You shouldn’t frown or tut when asked to provide an estimate because it’s an absolute necessity. Whilst we all understand that software development by its very nature is difficult to size, if you’re confident in your ability and in your process, giving an estimate at the right level (more on that below) should be easy.

What we should be focusing on is not removing estimates from the process, but turning estimates into something that are actually useful. I am under no illusion that education is required to achieve this so that people truly understand what an estimate is, but by trying to cut out estimates you’re just adding to the problem.

We need to be pragmatic. I’m not suggesting for one moment that we should give management a “man days” estimate for a project – that’s unrealistic and would just set everyone up for a fall. In my opinion however, it is realistic to perform a sprint level estimate which has the added benefit of getting your epic user stories in order and into a storymap before you begin. It’s a remarkably straightforward but powerful way of understanding how much work is ahead of you.

Get the entire team, including your Product Owner, together for the day. If you can, go off-site somewhere. Have the PO talk you through the project – the vision, the goal and of course the epic user stories. If you’ve got any supporting wireframes or designs – great. Once you all understand what it is you’re being asked to build, it’s time to revisit each epic one by one and talk it through in a little more detail. Based on what you know, ask yourselves as a team “is this something that can be tackled within one sprint?”. If it’s too big, then break it down until it does fit in a sprint.

Move onto the next epic. “Can we fit this in the same sprint as the last epic?”. If not, it goes into a new sprint. Rinse and repeat. At the end of it, you’ll be left with a storymap of the entire project – based on what we know now, of course. Ultimately this will eventually lead to the team feeling confident about saying that they need around N sprints to complete the work. From this we can create an indicative sprint plan and the estimation requirement is satisfied.

Of course, the usual caveats apply – this sprint level estimation is only based on what we know now and can only take into account the factors that we have considered at this stage. The detail will come in the sprint planning, but this should be enough detail to give both the PO confidence that you understand what needs to be built, and importantly the customer will have an idea of how much they will need to invest into their new project.

We don’t know, or want to know all of the detail up-front and this form of estimation caters for that. Be confident to provide an estimate like this and don’t shy away from it. Make sure your stakeholders understand the level of estimation you’re providing but be realistic when you provide it. Kicking off a project in the right way is essential, and starting with a good understanding of the goal, a storymap and an approximate idea of how many sprints will be involved is an excellent place to start.

Reinvigorate your daily stand up

The daily stand up (or daily scrum, if you prefer) is one of the core ceremonies for any Agile team. Providing a unique snapshot of progress, a good daily stand up is an extremely powerful way for the team to work through their commitments together, making sure to hold each other accountable for their work.

As the daily stand up happens at the beginning of the day, it’s easy for it to turn into nothing more than a coffee chat about what happened yesterday (or worse still, what the score in the football last night was). Because the stand up is a small part of routine, without the necessary focus it can quickly lose any value that it is there to provide.

First, remember why we have a daily stand up. Its purpose is for the team to update each other on their progress against their commitment. It’s a forum where blockers or impediments can be raised and taken away from the team. And, importantly, it should act as a springboard to start the day refreshed and motivated.

If your team are more interested in their coffee or toast than what is being discussed around them, introduce a ball that gets thrown around to whoever is talking. Don’t just throw it around the circle in order, though – have it so that you cannot pass the ball to your immediate left or right, but it can go anywhere else, thus making sure to keep the team on their toes.

Whilst routine is important, I’ve found that always holding the stand up in the same location can become tiresome and can often suck the energy out of the team. Here in the UK, the decent weather of our spring and summer months are all too short and so I always get into the habit of holding the stand up outside when possible. There is nothing better than a little vitamin D and the sound of birds chirping to get you in a positive mood!

Add some sunlight to your standup

Add some sunlight to your stand up

Ensuring the team are offering the right information can also become clouded over time. We’re not after a running log of what they’ve been up to, but we are interested in their progress towards the sprint goal. Changing the statement from “what I did yesterday” to “what I achieved yesterday” can often be a simple way of getting the right information out.

If the team struggles to identify what a blocker is, then perhaps start with the blockers before moving into progress updates. As an example, I’ve heard many times a team member say that they were pulled into numerous unplanned meetings yesterday, only to go on to say that they had no blockers. Work with the team to educate them on what a blocker really is and get them into the habit of raising them by focusing on blockers before progress.

Good time keeping is essential. If your team are struggling to keep within a 15 minute window, then introduce a visual aid like an egg timer. It’s also very important that you end the stand up right, rather than have it finish on a flat note. We want people to leave the stand up ready to go to work and so it’s important to end the stand up with a bang. Be motivational!

Like anything else that happened during the sprint, make sure you consider the daily stand up when you come to have your end of sprint retrospective. It’s an integral part of the sprint and so it should be discussed with the same regard as every other ceremony.

To wrap this up, I want to encourage you to pay particular attention to the smaller things. Simply changing the venue or the order in which people talk can make a huge difference to the engagement that you get from your stand up. Bigger problems will require more core changes, but start small. Keep things fresh, change when things become stale and above all else, make sure the team are getting what they need from them each and every day.