An Educated Guess is Still a Guess

In the real world…

Two weeks ago I moved house. I, obviously, needed to pack up my room. To do this task I had estimated both the time it would take and the amount of transportable storage I would need. I decided I could perform the task over three evenings, first packing the electrical devices, then some odd bits and bobs I had lying around and lastly, I would pack clothes. I had three big cardboard boxes, two large suitcases as well as a couple of rucksacks.

The good news was, I fit all of my stuff into the storage I had. Admittedly with some squashing of suitcases and some overflowing boxes – but I did it!!

Unfortunately, the time I allotted myself was nowhere near enough and I ended up packing until the early hours in the morning before I moved – but, hey, we all do overtime every now and then.

Even more unfortunate for me was that this move did not work out from the get go, and I’m now sat here surrounded by half-packed stuff – ready to move again. Joy.

The Educated Guess

Now that I’m packing again I felt this time I knew exactly how long it would take and what level of storage I would need. I had exactly the same amount of stuff as before and knew where everything was, easy!

Sadly, incorrect! The packing took even longer. I guess the stress of the double-move had a negative effect on my motivation for the task (I guess that’s why I’m sat writing this & not packing!). Also the boxes & suitcases etc that I had did not suffice and I had acquire another large box and another bag. How annoying!

So, what am i getting at?

In the software world most people estimate and size our work items before doing them, usually this leads us committing to do a task in this time. If we relate this way of working back to my real-world moving example…

On the first move the perception would be that I “succeeded”. All of the stuff that needed to be moved, appeared to be moved. Awesome. Except:

  • I crammed so much stuff into my suitcase that its broke the zip opening it. doh!
  • My boxes we so full that stuff fell out when carrying it – and I still can’t find my computer mouse…
  • I stayed up so late that move day was a real slog.

So, from this I would like to draw your attention to the dangers of doing anything (and at any cost) to stick to your estimate. That missing computer mouse could be a very damaging bug you overlook. Not only that, I “worked overtime” to get the job done. This caused a huge detriment to my ability on the following day – if moving was my day job i certainly wouldn’t be able to keep this up every week.

Second-time around is worse, I’ve already underestimated both the time and the storage I need. What’s the reason for this? Simple, this task [despite appearances] is not the same as the last one. First I have changed – lets face it moving twice in a fortnight is not a small amount of stress and no matter the task motivation is key. Secondly, the task itself is different. Okay, I’m moving the same stuff, but everything has a different place to be before. This is the same when writing software, no two tasks are the same, sure you can draw similarities but ultimately you’re just guessing again – and just because one task is similar to another you can still be wildly far off your estimate.

Is Estimation Really Worthwhile?

Getting better at estimation work as a programmer is a a skill that most seem to seek out. There are some great tips on how to get more accurate estimates, none more so than here:

But how much time must we spend estimating tasks? We can all sit researching the code base, assessing the backlog items until we’re blue in the face but ultimately, you will never know how long it will take until its done. Spending a large amount of your time preparing to give an estimation seems a lot like waste, to me.



So why do we get hung up on it? A lot of us run a SCRUM process and at the end of our sprints we’re either all very happy, or very depressed. Our mood is dependant on whether we finished the work that we, ourselves, estimated we could do before we started the sprint. If we do everything on time – we estimated well. If we have stuff left to do – we estimated badly. So why would we want to feel depressed after a two week slog of producing (I hope) great work because of a speculative call I made at the beginning of this process?  I think it is a much better thing to judge our work based on how good our work is – simple. But to do this we need to stop ourselves putting so much importance on our estimations – or at the very least prevent them from becoming a binding contract between ourselves and the business. After all, a certain agile principle does state:

“Working software is the primary measure of progress.”


Another way

I’ve been reading a fair bit recently on the idea of NoEstimates, which I believe can be attributed to Neil Killick. Read:

or check out #NoEstimates for a whole lot of discussion on this.

I tend to hear a lot that estimations are required otherwise we will not know we can deliver on time. This is fair, some people have clients and customers to keep happy. However, I have previously worked in a team that do not estimate their work, we ran a Cranked ( process. In this process, we did not fix the time of our iterations but the scope of them. By doing this, we can achieve some forecasting of work, without once having to guess how long a piece of work will take. All we did was take the range of time of our iterations (removing outliers) and multiplied by the number of work items a feature would require. Simple.

For example, say we needed to implement a login feature. This feature would require creating the back-end code, some form of UI and we need to make sure we restrict access to the application for non-logged-in users. That’s three pieces of work to me. The team’s average iterations take 2-3 days. So that equates to 6 to 9 days (3*[2 to 3 days]). Okay, its a simple example but the idea works. You keep you work items small and focussed and you ultimately don’t have waste any time estimating any more.

The beauty of removing this concern away from us programmers and techy folk is that we can just concentrate on making the product beautiful without spending our time or our emotional well-being on the concern of sticking to our estimations.

And this is just one thing you can do to help remove the waste in estimating – there is a whole bunch of material out there 🙂

Put simply

Let’s start making the quality of our code and the quality of the products we create our primary concern, not our estimations!!



More Than Just ‘Passing’ the Sprint

When running a SCRUM process you will have a product backlog with a list of items. Each of theses items will be sized at a planning meeting before they are brought onto a sprint iteration. All pretty standard. The point I would like to talk about is the sizing. Sizing is for everything. The design, the coding, the testing and whatever else you have to do. This means if you do not test the code then that item is not completed.

The problem

A situation arose once where a bunch of code was written to satisfy a product backlog item but it arrived late on the last day of the sprint cycle, no manual testing was done. This was handled not by declaring the backlog item unfinished but by carrying the testing work through to the next sprint as a new item – so it appeared the item had been completed.

The problem with this is not that work was not completed, or that work was carried forward. This happens, it’s fine. The issue is firstly with calling untested work ‘done’ and secondly the de-coupling of the coding with the testing. By doing this you sacrifice collaboration between the developer and tester – this should not happen. Collaboration is key to agile.

What’s the motive?

In my opinion it’s down to the fear of ‘failing’. But what really fails? Ultimately, what we want to achieve is creating great software. Agile/SCRUM are enablers for this. ‘Failing’ a sprint iteration because some work is incomplete does  not mean you fail to create great software effectively. It just means this time round, things didn’t go perfectly (when does it?), and one feature will be slightly later than expected . By measuring the success of your software based on the number of times you get a green tick next to the sprint, you’re likely to fall into some traps. Like in this example where you have had to fudge the principles in order to get ‘results’. Ultimately here you’re sacrificing your software in order for the audits to read well. To me, that’s a huge loss of sight on what’s really important – The software being the best it can be.

The Solution

The SCRUM guide states:

“All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.”

So there’s your answer. It’s the same backlog item. You re-estimate it. If part of the work is done (yes, that means its tested), then it is likely to be smaller next time around.

To me the solution is to also not to get too hung up ‘passing’ a sprint. If you tinker with the results just to get a result in the now then you will most likely never get a good grasp on your team’s velocity and find yourself in the same situation many more times.

Safe Environment For Your Agile Team


Creating a safe, enjoyable yet productive team happy can be tricky. Yes we all want everybody smiling at happy whilst at work but what if you think an individual or a team are not pulling their weight? or they are not following what you believe to be the process?

Finger Pointing

One method of raising such an issue I am adamant you should not doing is just to point the finger and blame that individual or team outright, especially in a group and definitely not at the retrospective. But isn’t that what the retrospective is for? I’m not say do not raise issues at your retrospective, I am saying do not make  people feel uncomfortable or unhappy in it.

How It Feels

Imagine going into work feeling down, your childhood pet has just died, or you just lost £1000 in a casino on the weekend. How productive would you feel when you’re feeling down? Let me tell you the answer is: not very productive at all. Directly calling someone out in a group of people is only going to make them feel worse (if, indeed, they were actually bad to begin with).

Are They Really a Problem?

First ask yourself: what actually is it they are doing wrong? Is it just that they generally don’t seem good at their job? If you can’t think of a specific thing they’re doing wrong, the problem is entirely your own. Grow up. If however, it is one thing you dislike about their work then speak to them, like a human being. Let’s say, for example, they are not (in your opinion) giving detailed enough check-in or code comments. Fair enough, its a small issue that is easily corrected.

What Should I Do?

In this example, check what others are doing first. It may be that they give just as much detail as everyone else but for some reason you have singled out this person. Grow up. Your point may, however, still be valid, It may be that everyone should step it up on the detail. That’s fine, raise it at the retrospective. Just say “hey guys, I like to give this much detail on my check-ins. Do you think its beneficial?”. That’s great, its constructive, you’ve not offended anyone and you have actually questioned your own process – so nobody will feel uncomfortable. If , however,  the person is alone in this then just speak to them. Wait for a good opportunity, perhaps the next time you pair on something and you’re about to check-in together. Just say “I like to give this much detail on my check-ins. Which I think is beneficial because of…..”. Once again you’ve not offended anyone, they have seen your point of view and if they disagree they will call you on it and you can have the conversation. If you have set them a good example, they will follow.

Don’t Invent Your Own Rules of Judgement

One thing to remember when you come across issues such as this is to make sure the issue is really an issue in the teams’ eyes. Whenever you think somebody is doing something incorrectly then make sure that is a rule made by (and agreed to) by the team. Just because you believe it should be done one way, does not make it so. Never criticize anyone for doing their work a particular way if it has never been agreed on to do it differently.