Getting low priority work Done

Scrum is great at getting an organisation to prioritise.  The Product Owner is responsible but clearly they need to get some level of buy in from other stakeholders a bit as well.  Having a prioritised backlog is a key component for successful Scrum.  It allows the team to focus on the real business needs of the organisation.  This is awesome.

Prioritised backlog

But when we start to aggressively question ROI on every single change that we make we often deprioritise work that actually does need doing.  Work that is more intangible often doesn’t get done.  Work that is low priority but provides the polish that is necessary to be truly proud of the work doesn’t get done.  Often these are the bugs that can be argued as features that really should be killed – but they never are and hence hang around – for good reason.  They actually are things that we missed or things that we could tweak that would make the solution a more professional one.  But because the current priority is The Next New Epic they don’t stack up in the prioritised backlog.  So they go unattended.

Why have you still not done this obvious stuff?

This generally goes on for a while and then a stakeholder gets irritated and asks why these issues are still not fixed.  The answer is simple – they haven’t got to the top of the backlog priority.  And then the interesting discussions start coming out.

Now we’re thinking

Suggestions arise such as – let the team take in say 15% of their time as low priority items that had been around for a while.  Or, let one person work on low priority items each sprint.  These suggestions are great as they show a commitment to getting some of this work that should be being done, done.  Perhaps the PO should have been prioritising a bit more.

But

  • 15%?  That is difficult to actually quantify isn’t it?  Unless we count it in number of days. And it rather defeats the point of the blackbox of the sprint.
  • 1 person planned with known assigned work during a sprint?   That impacts the rest of the team as it will need testing and deploying and potentially interact with their planned work.

These don’t feel like collective ownership solutions.

Some scenarios

I’ve seen different scenarios play out in solving this – some more team oriented than others

  • X% time – essentially reduce the velocity to give time for picking up the low priority work
  • Fixed chunk per sprint – take Y stories / X points in the sprint
  • Give it to the support guy – if you have a rotating support person on your team – either they do support or they do low priority work when there is none.
  • Give it to the support team – if your organisation has multiple teams and one rotates onto support – let that team pick up these items.
  • Do dedicated sprints for low priority items.
  • Just prioritise it like backlog always is prioritised.

I’d much rather see the PO plan the work.  Potentially with the team taking 1 story per sprint to deal with it.  Maybe put it at the end of the sprint’s backlog so that if anything falls out of the sprint, this work does.  Then at least they can plan and prioritise it and work collectively.  And share the responsibility of getting the work done.  Kind of like Scrum intends!

I personally prefer the approach of incrementally dealing with a bucket load of work.  For things like technical debt (which some of this may be) or low priority work or minor/trivial bugs – I’d rather see a product owner prioritising a small number of these into every sprint so that the product is continuously being improved.  But sometimes that is harder to sell – particularly when you’re doing date based releases and you approach the deadline.

You do however need to tend and care for your system and for your users to make sure that you are slowly making progress about the stuff they care about – even if it isn’t the thing that will make the next big impact on the bottom line of the company selling the software.

Has it happened to you?  It would be interesting to hear other people’s experiences with this.  How have you solved it?  As I suspect this is quite a common scenario.

Advertisements

Permission to Size ScrumMaster?

When I first heard about Scrum one of the distinct messages I heard was of a planning meeting where all involved in the product – devs, testers, business, managers, etc – all sat in a meeting and played Scrum poker in order to agree on the relative size of the work.  This translated into a beautiful scenario where everyone involved bought into how much work is being done and at what rate as they were all jointly involved in the sizing of the work.  There was no frustration at the rate of progress as the velocity was understood and the sizing was communally agreed upon via conversation and mutual understanding.

This is possible a utopia.  But it is an interesting perspective on the sizing game and group buy in.  I’m not sure anyone actually does this.

In a previous post – The dual faces of Sizing – I identified two types of sizing that may occur on a Scrum project.  I avoided the question of who exactly was doing that sizing.  Is it the utopia of all stakeholders who care?  Or is reality, necessity or practicality different from the utopian dream?  And is that utopian dream even desirable?

1. Who sizes for release planning?

Ideally you want the entire team involved.

However you might be able to get good enough with someone who is both familiar with the new stories – possibly having been involved in understanding them and writing them – and who also is highly familiar with the team’s sizing and therefore can give a reasonable approximation as a team proxy.

If you do this, measure the changes so that you can understand the amount of change for future planning.  Metrics are your friend – if you measure, and if you use the measurements effectively to become more predictable in the future.

2. Who sizes what comes into a sprint?

Going back to the opening story – should the business people be involved in the relative sizing of the work that they will not be doing.  No.  Yes.  Maybe. Maybe not.  It depends.

Here are some options – and some ideas as to why it may be good or bad.

a) Only those that actually do the work have a say in the sizing

On the one side, sizing should be an activity for those who do the work.  They actually have to do it, so how can anyone not doing the work actually say anything about the size of it?

The complication of this model is who is “the team”.  Is the ScrumMaster in the team or outside?  Is the Product Owner in the team or outside?  Is the architect who writes no code but acts as an acceleration agent in the team or outside?  It becomes difficult to differentiate who is in and who is out.

The biggest pro is now the team has defined how big the work is.  They buy into the size of the work and they will be the ones committing to doing the work.  This model allows them to have the whole say as to what the work is.

I suspect this is what the majority of teams are doing.  It avoids some dysfunctions by not allowing them to be options (like overpowering stakeholders) and it fits into the ScrumMaster mantra of “Protect the team” and “Let the team decide”.

b) Everyone can come to the party

On the complete other side, collaboration is a key agile concept, including everyone in the process increases the common buy in and understanding of the impact of the work.  These discussions can allow for increased transparency and buy in to the rate of delivering the software.  This could be incredibly powerful for group ownership of the deliverable and allow those not doing the work have a say in the destiny of the project.  It allows them to feel like they can impact the deliverable by them understanding what the impediments and the time sinks are.  This can bring the discussion far closer to allowing the customer direct input into what they actually get – not only with the final solution but also the trade-offs along the way (speed vs features, etc) – which is a good thing.

The difficulty with this model is that significant issues can arise if the relationships with all involved are not of an equal level.  If the CEO is involved with sizing then s/he may significantly overpower or influence the process which may lead to the process becoming meaningless.  If you have a dysfunctional situation in your environment then this is the worst thing you can do as it can significantly impact the team buy in to the size of the work and could be a failure in ensuring the team is protected to do the work the way they feel best.

c) Everyone who has value to add to the conversation should be involved

Is there a middle ground between options a) and c)?

The complication with option a) is that it may exclude people who have valuable insights to offer.  If you exclude the Product Owner from the sizing activity you may lose the conversation that shows that the team has misunderstood the requirement that the PO is putting on the table.  If you exclude other individuals who have value to add, you may also lose their conversations that may help in identifying the full extent of the work.

There are variations on this model – perhaps you could have the PO and/or other involved parties provide the sizing after the initial team sizing.  This allows the team to understand what they believe the work to be – while adding in the additional conversation from the PO and other interested parties after the fact.  This two phase situation would only be needed if there is a dysfunction that allows the team to be overridden by individual power structures.

A dysfunctional example – minorities must have a say!

An example of this dysfunction could be a team with 4 developers, 1 tester, 1 PO, 1 ScrumMaster, 1 Usability expert, 1 document writer all sizing the work.  If the goal of planning poker is to pick the majority view, and the tester, PO, usability expert, doc writer and SM all are voting – and they vote an 8 when the developers are all voting a 13 – by the majority view the story is an 8.  But this may be a dysfunctional decision.

In an equivalent example, assume a team of 4 developers, 1 tester.  If they are the only people voting and the devs all vote 8 and the tester 13 – again, by the majority view the story is an 8.  This too could be a dysfunctional decision.

In both of these examples – the minority needs a say.  If a tester identifies that the testing of this item – their activity – is going to be a significant amount of work on a given story then they need to identify this and the team needs to acknowledge this in the form of discussing and perhaps accepting the tester’s sizing over their sizing as there are factors that they aren’t taking into account when thinking about the sizing.  This is the point of planning poker.  The key is conversation.  The ScrumMaster needs to facilitate this activity to ensure the voices of the minority are heard and not squashed.

So should the Product Owner size?

It depends…

If the PO is going to attempt to significantly influence the team – then no.  If the PO is using the voting opportunity to show up disparities in expectations – then yes.  The difficulty is to work out the POs intentions and to respond accordingly.

The other key reason for the PO to be involved in the voting process is to perhaps engage with a discussion on how we can simplify the implementation.  But that could be done with voting or as just a conversation around voting.

The key problem with a PO voting is clearly that they often are leaders in the organisation and wield more influence in the team and hence may cause problems as a result.  Manage that, and things will work themselves out well.  In fact it may empower the team more by having the PO involved and allowing the team to see that they can vote their way and not be overpowered.  It depends on the PO…

So should a ScrumMaster size?

It depends…

If the SM is going to reduce their ability to facilitate the voting in the previous dysfunctional examples then they should not be voting as their involvement could make them appear partial to a given outcome.

However if the SM is a team member – delivering software as well (which is not an uncommon formation in a Scrum team) then they may have value to add by voting with their team role hat on.

Another scenario that I can see is if the SM is the longest serving member of the team –who has domain knowledge and understanding.  Perhaps they were team members before they transitioned to the SM role, perhaps the rest of the team is newer than them.  In these scenarios excluding them from the sizing activity may lose valuable insights.

However in these scenarios the SM could come in with secondary questions such as – I thought it might be an 8 because we may need to integrate with the old email client which has a difficult monolithic interface – what do you guys think?

To close

I’m not sure the utopian idea of everyone group hugging and agreeing jointly on the size of the work in a meaningful way would occur in reality.  It could be a good experiment.  But it might be messy.

I have always sized as ScrumMaster because I’ve had good insight into the work that the team has been doing.  However in the current organisation that I’m in, I can comfortably sit back and not size as I don’t have the history and I don’t add value to the equation for sizing yet.  So for now, in my currently role, I won’t be sizing anymore and I’ll monitor how that goes.

I noticed most POs prefer not to size – or don’t take sizing too seriously.  Either way, that’s fine with me.

The key goal is as a conversation enabler to allow deeper understanding.  That, and as a metric to help measure the rate of progress in order to approximate the range of potential delivery dates of course!

The dual faces of Sizing

There are two distinct phases of sizing that can occur on your average Scrum project.
1. Sizing for release planning
2. Sizing for taking into a sprint
Both of these sizing activities is important and distinct from the other.

1. Sizing for release planning

The goal when sizing for a release is to get a gut feel of how big the release is in as quick a time as is reasonable / responsible.  Activities such as Magic / Affinity estimation are invaluable as they allow a lot of stories to be estimated in a short amount of time.

The goal is not to lock down the sizing or to discuss the implementation or design in details nor to look for minor flaws – though it might be useful to point out obvious ones early.  The main goal is to get a gut feel of how big this thing is in order to make some decisions and hopefully understand how long it will take if you start working.  Sizing at the release level acts as an aid to help you keep sort of on track.  My experience is that for 3-6 sprints of work this is good enough to deliver to.

Sizing for release planning is always on a good enough basis.  The team will always be able to revisit the sizing once they have had a longer in depth discussion about the content in a grooming session or SP1.

2. Sizing for taking into a Sprint

The goal when sizing to taking a story into a sprint is to make sure the team understands the story well enough to confidently say that the story is a given size relative to any other story in the release.  A key component of this sizing exercise is the conversation that occurs when the team sizes the story with Scrum poker.  It is important for the team to have a conversation if there is a disparity in what each team member believes the size is so that the team’s knowledge and understanding can grow about the work they are about to do.

Resizing

If an estimate comes from the initial release planning estimation – then resizing should occur when the conversation about the story has happened in grooming or sprint planning.

If the sizing comes from a previous estimate made in grooming or sprint planning then the size should only be changed when new information comes to light that effects its relative size to other stories.  This helps reducing sizing churn as everything is relative to each other.  Resizing a single story without any new knowledge would then affect other relative sizes which may have an unintended ripple effect on the size of the backlog that doesn’t make sense seems as it is all relative – and the velocity is relative to it as well.

If a team starts a story and discovers new work while working on a story that was not included or couldn’t have been anticipated in the sizing of the current story a new story should be added to the backlog to accommodate the new functionality.  The story shouldn’t simply be resized to include the new functionality or delivered with the new unplanned functionality as both of these actions hide what has happened with the story and may lead to the story that was being committed to for the sprint not being completed.  A new story will allow the changes to be tracked effectively – and planned for in the future.  A new story will ensure that the team can continue to work towards the functionality it knows it is committing to in a sprint.

Metrics for planning the future

It can be interesting for the Product Owner and/or ScrumMaster to track the differences between the initial sizing made for release planning and the actual sizing once the conversation occurs for sprint planning.  It can also be interesting to track the amount of work missed during the initial release planning.  Both of these data points can help to inform future planning as to how much we usually change between the start of the release and the end.  This could help increase predictability by allowing the planning to take this into account in the future if necessary.

Size early, embrace change late

Early sizing is great – but don’t over complicate it with trying to make it precise.  Rather make it quick and good enough – then revisit it when you have the time for each story.  Track the amount that you increase on average over time and use that to increase your predictability if possible rather than wasting lots of time upfront and fighting the change at the end.

A retrospective on a planning talk

I gave a talk at SUSGA on Thursday evening.  The talk was entitled Release Planning with Scrum: Controlling the Chaos.  My slides can be seen here.

I think the talk went well.  I think it was well received overall.  We did touch on a couple of topics that weren’t specifically under the auspices of the talk that I’m sure I’ll blog about soon.  But the content itself seemed to be understood and generated much conversation – which is largely the point.

I did learn a couple of good things

  • When I know my content, I’m okay at presenting.  This is good 🙂
  • Karen had a great comment of how to deal with sizing of epics when turning them into smaller stories. Simply generate only as many stories as fit the number of points. Once you’re over that amount – either cut stories, or admit scope creep.  (And I would add – measure to understand the growth)
  • I don’t necessarily tow the party line in my view of certain topics.  I’m sure I’ll blog about some of those soon to explore both my thinking and hopefully get feedback from others.  That interaction/conversation in my mind is largely the point of why I blog so I’m sure it will be fun.

I would do a couple of things differently

  • I should have written up bullet points on the points that each group brought up so that they could be remembered and blogged.  I intended to, but I only remembered half way through the discussion.
  • I would touch a bit more on release planning versus releasing software – i.e. when you’ll get something versus when something will be live.  You still want to plan to know in a ball park manner how long it will take to get something specific even if you release software into the wild every sprint.
  • I practised a lot – which is great.  But based on that practice I should have changed my slides as by the time I got to the presentation I knew all the points around the points on the slides so I could possibly have achieved less PowerPoint hell.  Perhaps next time I’ll create two sets of slides – one to practice until I know what I want to say.  And the other the cool image laden slides that I can talk about.  Something to think on.  I’m not presenter type so I’ve got lots to improve around this.
  • I suspect one or two people do release planning very differently.  I should have stressed that this is the way that I have done it, and that I’ve found success, but by no means is this a blueprint for the only successful way to do release planning.  Between the PMI comment (that this is “practical agile”) and the comment that the talk was good as I presented my content well – there were certain people who possibly think what I’ve been doing is overkill and maybe not agile…  but I’d love to hear what the other options are in helping stakeholders understand and take part in what is happening.

The interesting thing is I wasn’t nervous until the hour or so before the talk.  That is progress too. I’m starting to get better at this public speaking thing.

Thanks to everyone for the support and positive vibe of the evening.  I think it was great.  And hopefully it inspired some ideas, thoughts and conversations in the community that we are.  If that is all that happens, then I’m happy.

And thanks to the Yellowtail crowd who made it out.  It was really great to see you all again 🙂

Tracking Progress

A while back I was part of a panel talking about tools at SPIN.  Peter Hundermark asked if I viewed the board or Jira as the final say over what was to be done.  I guiltily admitted that actually I have a spreadsheet that I consider the definitive.  This post is about that spreadsheet.

An example of what I’ve created over the last two years is my Product Overview spreadsheet.  In recompiling this today I’ve already identified several changes that I should make and several changes that would be nice to make.  But I’ll hold off on any of those until I’ve determined the needs of my current projects.  We shall see.

Ideally I’d like Jira to be able to do it for me.  The latest version seems to be doing more so I’ll see if I can automate this more – or replace it.  But previously I’ve been unable to get what I wanted from there.  And it can change from so many different angles that it may be hard to track.

Why yet another spreadsheet?

In order to identify trends in a release – you need to know how big it is and how fast you’re getting there so that you can plan against it.  If you’re not releasing every sprint – but rather every 3 months – or when it is ready – this can help you understand realistically what will be in the release – or when it will be ready.  This is a Good Thing.

I’ve found using this spreadsheet that planning medium term releases (4-6 sprints) can be very accurate.  Over the short term velocity may vary too much and over the long term too much will change.  But I’ve found that planning over the medium term can be very effective.

Some details:

The key page is the overview – as that is intended to inform as to how we’re really doing.  It covers the estimates of dates based on best, average, worst velocity.  In this version I’ve got a fixed date line for “Required” which helps manage to the date.

The product burnup is useful to understand the rate of change vs. the rate of progress.  If you draw a best fit line for the completed items and another along the change items – when those two lines are extrapolated to meet should be when you ship.

All the data is automatically generated from the other sheets.

The sheets are:
– Overview – executive summary
– Themes – if more detail is desired on the themes in progress
– Sprints – details on each sprint (sprint totals are generated from the completed backlog items)
– Changes – to enable the tracking for the product burnup
– Backlog – the backlog – estimates and sprints and status (complete or otherwise)

Pros:

I have found this spreadsheet invaluable in planning releases and discussing progress with stakeholders.  I keep it up to date and provide it after each sprint end and it keeps a simple eye on the progress of the release.

Cons:

It takes some effort to keep up to date.  If you keep on top of it, it is easy.  And it generally takes a 1/2 day or less to update.  But if it gets out of sync it can be a pain.

It would be lovely if Jira just did this for me 🙂  (Or I could export the data and add the forumalas on top of it more easily…)

Todos:

I’ve realised this weekend that the SUMIFS and COUNTIFS are not supported in OpenOffice – so I’ll need to do something about that (maybe).

I’d like to push the theme related stuff to the themes sheet and make the overview page even sparser.

It needs to be easier to change sprint length – or deal with changing dates due to public holidays changing the cadence – or to deal with hardening sprints when no points are planned (hence this _maybe_ shouldn’t influence the average velocity).  That is a bit of a pain at the moment.

After looking at this again this weekend, I can see some potential for refactoring – some DRY and SRP could be applied to some of the sheets I suspect.

In closing:

I’ve had great success using this spreadsheet.  Having the numbers and keeping on top of the empirical information lets you plan further ahead and help people understand what they will realistically see in a release based on real progress and due to real changes.  This is a Good Thing.

I want it by October

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.