It is often the case that a client or a boss (or his boss and so on) comes to you and says “I would like have the Foo module by October”. There is generally very little technical understanding of what Foo may be. Often there is very little business understanding of the scope of what Foo might be as well. So what do you say?
Step 1: We can do something
There are a myriad of options. Yes. No. Maybe. What is Foo? I’ll need a full spec before I can commit to anything. I’ve said them all. I’ve worked with them all. None of them make anyone completely happy. In general – if the date is in the future – I now go with “Yes, we will be able to do something, I’m just not sure yet what exactly that will be.” So that isn’t no, but it isn’t yes either.
The problem is that no one may know what Foo is yet. So how can you with provide an answer to this question with any amount of value?
So we’ll be agile about it – and if we prioritise well – we’ll get the right things done. That is what our track record says and we’ll continue to do it.
Aside: What if “something” isn’t enough?
But what if there isn’t enough of a Minimal Marketable Product by the date? Do we work harder? Hire more people? Fire some people? “We don’t know what will happen when you add 2 people to the team” isn’t a particularly useful answer but it is the correct one. The business side of the equation needs to understand that as well. Adding more people is well known not to be a short term solution – even if you can find people good enough to add. We need to work to manage demand and optimise the flow of delivery. Everything can’t be delivered in October – unless we only do one release a year – and then it becomes “which year?” 😉
Step 2: Define what it is
In the past I have worked starting with the one liner of “I would like Foo completed by October”. From this often an RFC is initially written up by my PO. I’ve worked with the PO to generate a list of stories. Most recently those stories arrived with no input from me. Based on that list of stories we can now start discussing both what is missing and the realities of what it might mean.
Step 3: Size it
At a point where we believe the backlog is defined enough (which may be quite early) we then do some sizing.
I have in the past done a 4 hour estimation session – 2 to 3 minutes per story – with the whole team. It was unpleasant for all concerned. Since then I’ve done affinity / magic estimation and it works like a bomb. In the most recent session I tried to compare my estimates made before the team did the sizing to that which the team came up with. They were pretty close – and as the team progressed and resized items as they better understood them they came far closer to my original sizing. But I haven’t yet used my sizing for initially planning yet 😉
Step 4: Plan and forecast
So now we have a backlog and sizes have been applied by the team to the items. This is very rough! But it is good enough to manage within a couple of sprints – assuming that there isn’t a lot of unexpected work.
From the size we can take average, highest, lowest, last velocity achieved for the team and provide some forecasting as to how long it will take to deliver the known work. Generally I’ve been working in 3-4 sprints worth of work and this has been relatively reliable within a sprint or so. So you can agree on a reasonable date based on past experience of the real velocity and padding for stabilisation and backlog growth where you needed. Everything changes, so expect a little change – but sometimes the client / boss would like you to not – in which case show the change visibly in order to show why you should have planned for it in the first place.
Step 5: Manage expectations transparently
From here on out I report on progress with complete transparency. I report on change – up and down. I report on actual work completed. I report on the amount of remaining work and how that may have changed. I work on how the last sprint has changed the average, highest, lowest and last velocity and how that influences the potential end date spectrum. I report on this Every Single Sprint.
Practicalities: Sometimes you need a date, but try not to
My current process that I’ve been using for the last two years is possibly not very agile. But when a date is asked for and that is what the client / boss is managing to then you sometimes need to provide one. And then you possibly need to argue what to change in order to stop managing to the date. I’ve (maybe) just won that argument – but we’ll need to see how that project continues.
Step 6: Replan every sprint – the numbers don’t lie
The beauty of this is that the numbers don’t lie. It is simple as that. We can be hopeful and optimistic and plan on the best velocity – but if we’re consistently not achieving the best velocity that will continue to self-correct every single sprint and the end date will move accordingly. If we don’t discuss the information that is radiating out of the figures then we have our heads in the sand and we’ll fail. Managing the expectations continuously and early will ensure more probability of success.
Step 7: Be Successful at what you know
Success is a relative term. Managing expectations and ensuring that we’re successful with delivering what we know ensures that we’re successful. Managing the change so that we can be as agile as the client / boss will allow us to be ensures that we’re successful. We can’t do magic. But we can manage the reality or what is actually happening Every Single Sprint. And everyone can embrace change and be successful. Or fight it – and hope to be successful despite the need for change – it is possible.
Are there other ways to plan?
Of course there are. There are vast options on the planning tree. When it comes planning without involving the team there are many options. At my current organisation there is a magic spread sheet that turns input into days based on numbers of developers to understand a guess at the size of the work. The bottom line is that no matter what the original plan is on day 1, there is a good possibility that it will change at the end of the first sprint based on the feedback cycle from that sprint. Embrace that information and deal with it rather than hide it and pretend we’ll do better next sprint.
Scrum provides an amazing opportunity it empirically measure progress and hence reset the planning at the end of each sprint. Ignore it at the risk of failure.
But is it agile?
I’m not convinced that what I’ve done in the past has been very agile. The PO and myself have done a lot of preparation work in order to ensure that the backlog is defined enough and able to be sized. All the stories are small enough. We haven’t been looking at epics. This can take a reasonable amount of effort and be wasteful. But it avoids including the full team until a full understanding of what is wanted is obtained.
Recently we’ve had the scenario where the RFC was understood but wasn’t “signed off” so we couldn’t start working on it – despite knowing that there were solid chunks of work that were very unlikely to changed. That is waste and not very agile at all. That is one of the things I’ve been frustrated about and have wanted to change.
Recently the PO has started working more closely with one or more team members to define the backlog better. It will be interesting to see how that pans out with a more collaborative generation of the backlog.
I’ve also pushed very hard for us to be more agile about the requirements definition. Let’s work it out as we get there – let’s rather embrace a little more ambiguity in order to avoid the in depth up front work for the PO and stop fighting the ambiguity as the RFC isn’t perfect. However we do work in a remote scenario so this might turn out to not be such a good idea if the PO isn’t always available.
Equivalently with ambiguity comes less predictability on that Big Date that we may be managed to. However I believe we have an agreement that the date isn’t usually an important feature so we should stop managing to that. And get some of that continuous delivery going with more releases more often.
Aside: Are dates reasonable?
Is the original question reasonable? Of course it is. A CEO wants to make a deal and needs to know if something is possible. A managing director needs to move forward with a product and needs to know if a certain client can be supported in a certain timeframe. A managing director needs to be able to calculate the ROI for two different streams of work and hence needs to know the relative sizes of the work. These really aren’t unreasonable business requirements. But they all need to be weighed up and balanced to ensure that in the timeframe required we can deliver the highest priority items for the business. That should always be driven by the business. But the business should still ask us before committing. And we still can’t do more work than we’re capable of.
Step 8: To close…
This is how I’ve been planning. Continuously feeding back on the progress. Get the client / boss to understand what that means. And fight the fight when it comes to a head that the “date” isn’t in the planning – or hit the date because the velocity calculations make the delivery vastly more predictable than other methods so you can actually get the date right – or even deliver early. Rather do that than deliver late.
I’ve had really great success delivering predictable releases with the above. There is no magic. Just a little maths, a lot of measuring and strong will power to help the client understand. Hopefully this can help others to be more successful as well.