Prioritisation is a technique for establishing an order for the work to be completed that provides the business with the most important things first. Unfortunately, the MoSCoW (“Must have”, “Should have”, “Could have”, “Would have”) method usually results in 85-95% of “Musts” which effectively renders the process redundant. If we assume that we will only release the software once the key business stakeholders are happy that the critical features are present then it is more effective to regularly order the backlog rather than simply apply MoSCoW. The “Musts” will become apparent as the software evolves and people are actually using it.
Follow these steps every couple of weeks or so to make sure that you have a nicely groomed and ordered backlog to feed into Sprint planning or your Kanban queue:
- Get the Product Owner and any other stakeholders that have input into business priorities into a room
- Explain that the meeting is timeboxed to 30 minutes
- Reassure everyone that while you will be asking them to perform some tough prioritisation decisions, the exercise is not about moving requirements out of scope – it is about establishing a priority order to allow the team to deliver maximum business value
- Lay out the product backlog index cards on the table (if you have more than 40 items on the backlog then generalise some items into epics or themes so that you only have 40 or less cards with you)
- Ask the participants to split the cards into two equally sized columns – priority 1 and priority 2 (if you have an odd number of cards then allow them an extra card in the priority 1 column)
- Once this is done, rename the priority 2 pile as priority 3 and put aside
- Now repeat step 5 for the priority 1 cards
- You should now have 3 columns (in priority order) of cards, with no more than 10 cards in each of the first two columns
- If you still have time, you can now ask the participants to order the priority 1 cards – this can be quickly achieved using a bubble sort technique
- Ask the participants to choose between the top 2 cards – if their choice is the 2nd card then swap it with the 1st card
- Now ask them to choose between the losing card and the next card down – again, swap if necessary
- Repeat this process until the 30 minutes is up or until the participants are happy with the order
Example bubble sort of numbers:
7,5,9,3,1,4,10,8,2,6
1st sort: 5,7,3,1,4,9,8,2,6,10
2nd sort: 5,3,1,4,7,8,2,6,9,10
3rd sort: 3,1,4,5,7,2,6,8,9,10
4th sort: 1,3,4,5,2,6,7,8,9,10
5th sort: 1,3,4,2,5,6,7,8,9,10
6th sort: 1,3,2,4,5,6,7,8,9,10
7th sort: 1,2,3,4,5,6,7,8,9,10
Good luck and happy prioritising!
“Everyone knows they’re a guess. Everyone knows they’re wrong.”
Spot on. I grew up in a generation that was taught to estimate with slavish attention to detail, in the sure and certain knowledge that these quite arbitrary figures would bear no relation to reality, and worse, that no-one would really care. So there was no incentive for the farcical delusion to be tackled. We were all just taught to go along with it.
It all bred a deeply corrosive and cynical attitude to management, and the way that people (whether team members or users) should be treated.
We knew we didn’t know with any reasonable degree of confidence how long the work would take. We knew we couldn’t know at the outset, and we were taught not to care. We were taught to tolerate dishonesty, and punish honesty.
Uncertainty is the reality. Certainty is delusion.
What if you do not have a set budget? I’m thinking big corporate projects here, company is willing to spend millions and millions over decades; assuming that you release every once in a while and get sales, etc.
The obvious question the business asks then is, “when will feature XYZ” be done (so that I can prepare sales/marketing/other non-development departments)? Fair question, yes?
Thanks for you comments Erik.
The answer to “when will feature XYZ be done” (cycle time) can be answered very easily using Little’s Law, based on the team’s throughput (number of stories delivered per day) and queue size (Work In Progress). If the team is doing Sprints and the feature is top priority then it will be delivered in 1 Sprint (or more if it is too big, but how big will be determined in Sprint Planning).
If the team is doing Kanban then they will know the WIP and throughput and therefore can give an excellent prediction as to when the feature will be delivered with no guesswork involved
You’re make a huge assumption in that the team can split epics into approximately equal-sized stories. If true, I completely agree, story points are irrelevant. I think defining stories of equal size requires an experienced and proven development team. It takes time (many months, if not years) to achieve that level of sophistication.
In the end, I think estimates matter though delivering value matters more. I’d agree that we spend too much time estimating and managing estimates. However, that doesn’t mean that we should stop estimating entirely. Let’s allocate less time to estimating and more time to story sizing.
Thanks for your comments Vin.
I’ve actually found that even if the stories are not of equal size it doesn’t really matter because in a well defined backlog their size averages out over time. To be honest though the only reason why it *may* be important to have stories roughly the same size is if we are trying to predict the future, i.e. we want to guess the delivery date or how many stories can be done by the given delivery date.
In my experience the number of stories is a good enough predictor of these things without explicitly needing to spend time breaking down stories to the same size. My argument is that this rough sizing naturally happens over the course of time in iterative development as teams define just enough work (tasks) to fit into their timebox and natural variances in scope occur.
Another thing to consider – in order to predict the future using story points or story count we need to define a full backlog up front. But we shouldn’t be defining a full backlog up front if we’re Agile, right?! Moral: don’t try and predict the future when building software. Make your future predictable with hard dates based on budget or time necessity.
A very interesting idea and one that has been around the traps of our mind for a while. Thanks for crystalising thoughts and starting this discussion in earnest. While totally open to the idea, one sticking point that I would like to get your views on is the area of a businee case.
In any medium to large organisation the conception of a project happens when an idea gets put on paper and a rough budget assigned to it. I call this the cost appetite and is normally based on a gut feel for the benefits. The next stage is to get some sort of approval to move to the next phase, which is the first business feasibility study. This phase is sometimes called concept, inception, ideation or even discovery. The end product of this phase is a business case. As everyone knows a business case requires costs and benefits and an indication of the value of the idea, oftern represented as NPV. The team size is not known at this point and one of the objectives of this business case is to be able to decide on the team size based on size of the benefits. If the NPV is huge we may want to assign a larger team to it in order to deliver faster. I’m not sure how we could estimate the cost by using a tentative team size at this concept stage?
Organisations always have more ideas than resources and prioritisation and portfolio governance are key to ‘doing the right work’. NPV is one of the key prioritisation criteria to compare and choose between various concepts.
How can we arrive at NPV if we have no estimates?
Apologies Phil I didn’t reply to you earlier!
My approach here would be to start with a small cross-functional team, work for a few Sprints and then assess the progress and whether we need to scale up. It should be remembered though that large teams do not necessarily deliver faster. There are diminishing returns for every person you add to a team. Small teams are nimble, can easily adapt and evolve their processes, can collaborate more easily and simply get things done at sometimes astonishing rates. So clearly if the body of work is huge we need to consider a scaled Scrum approach with x amount of small teams working from a common backlog.
Again, I would not want to base the success or failure of my project on guesswork, whether it be to establish a delivery date, budget or team size. Pick these things, work, generate data then use that to predict the future if you must.
Great Insight. Completely inline with my own personal observations, feelings and experiences. Predictions should be made from facts, not from guesses and crystal balls. Facts are provided by what the team has done in the past, not by what everyone wishes the team to do in future. XP, yesterday’s weather.
Thank you Christian, I completely agree
But what do you do with fixed scope projects? If a team is building a manufacturing control system, they can’t deliver something that only half builds a car, the business gets no value until the software is producing whole cars. Are you saying it’s simply impossible to create a budget for such a project?
Thanks for your comments James.
Of course you can create a budget for any project. But by basing budgets on estimates they will be wrong. Anyway, IMHO there is no such thing as a fixed scope software project – they are a myth. I do not believe it is possible to fix scope, i.e. nail down every single detail of every requirement up front.
But the real point is – why would you want to? Until you start building software you simply don’t know what will work and won’t work in terms of architecture, UX, UI, everything. Smart companies are building iteratively and not allocating huge budgets for projects. They are spending money on short iterations of building prototypes or MVP’s and then continuing funding if the product has potential for providing sufficient value to warrant the investment.
If you truly think you are building a system that has extremely detailed and well known requirements (such as your example), and there is no chance that anything will change from your detailed specification, then I would suggest that such a project is not a candidate for an iterative approach, hence Agile is ill-suited.
However, all that aside, let’s say you do have a fixed scope project and you want a budget without estimating. Could you not still break down the work that needs to be done into small, similarly sized chunks, spend a few weeks working on the software to give you throughput data and then project that figure out? So, if your teams gets through 50 of 200 work items in 5 weeks then the predicted delivery date would be in roughly 15 weeks time. Assuming you have a fixed, 100% allocated team you can calculate the cost which will give you your budget.
If you want your budget before work starts then you’ll need the team to guess how many work items they can get done in a given timeframe rather than use real data, but as long as you adjust as you go along you can at least see if you are on track to be within budget.
I think possibly you have hit the nail on the head with saying that not all projects are suited to agile development… at the extreme, flight control systems are the sort of thing where you want to (and this actually does get done in practice) bed down requirements to the nth degree of detail up front, and then you can very accurately estimate them. But no web/mobile application would ever be in that situation.
In the experiences I’ve had estimating using story points, managers haven’t put expectations on teams about delivering a certain number of story points per iteration, and I (a developer) certainly have never felt any pressure. Maybe I’m lucky. Rather, story points are used by product managers to prioritise, and for teams to measure their own performance. Note that it is them measuring their own performance, not someone outside measuring the teams performance. They use the information for their own purposes, ie self improvement. They are not asked to explain why one iteration they delivered 40 story points, and the next they delivered 20, though they may ask themselves that, and they may have reasonable explanations (eg unexpected scope found in a story). So they are not pressured to perform to someone else’s expectations, but as trustworthy professionals they seek to maximise their own efficiency and performance. In this case, I see no harm from story points.
It seems to me that what you’re proposing is that stories become the new story points. How does that remove the fear/pressure that a developer might have of delivering enough? In a situation where such fear exists, won’t it just mean that they break stories down into smaller stories for the sake of keeping expectations low? The problem there is not how the amount of work is expressed (whether it be in story points or in stories), but that there are unreasonable expectations, or fears of unreasonable expectations. This is what needs to be addressed, and this is much more a people problem, it involves building two way trust and professional respect between managers and developers in a company.
You make some excellent points James. And it sounds like you have been fortunate to work in supportive cultures that don’t use estimates to hammer teams.
You’re spot on – it’s a people problem. Story points were intended as a means of enabling the team to improve their performance. With the “fear and pressure” elements in place, even if teams don’t estimate they may be pressured to split stories into smaller and smaller tasks in order to increase their throughput.
But whether the environment is supportive or destructive, the argument remains that story count, along with developers breaking down stories to generate the conversations, is potentially a better way to go. Delivering stories (tested, working software increments) means something to the business. Delivering story points doesn’t.
Here’s another reason to make stories as small as they can be.
One of the best techniques for preventing gaming (e.g. story point inflation) short of not actually estimating at all (see Neil Killick’s post bit.ly/I1qGX4) works like this:
1. During sprint/iteration planning, instead of story points, gummy bears, NUTS, hours, or ideal days, have the team commit to how many STORIES they feel able to complete. Use the usual method of presenting one story at a time starting with the top of the rank-ordered backlog. No cherry-picking allowed: start from the top and continue until “full”. Encourage questions to clarify intent and then stop when the team isn’t certain it can commit to any more.
2. Keeping the focus on the story, which is after all a statement of something that has value to the customer, makes measuring success easy.
3. If the team needs to decompose a story down into smaller chunks (thereby increasing the NUMBER of things being delivered and thereby GAMING the system), then by all means go for it!
4. This actually works to everyone’s benefit: stories can only be broken down so far. That point turns out to be the point at which the story is most completely understood by all, i.e. it cannot GET any simpler, so it’s a natural limiting factor.
So the reason this works is because it’s simpler, faster, and trying to game it actually produces a desirable outcome. Credit goes to Cris Sims who introduced me to the idea.
Thanks for your comments Bob.
I completely agree, breaking down stories as small as they can get is excellent practice, not least because it is a great way of making stories roughly the same size, meaning that predictability is improved and throughput measures are more accurate.
But instead of asking the team to guess how many stories they can get done, why not simply use current throughput as the Sprint forecast? Of course in Sprint 1 it comes down to a guess, but after that you have data to use.
Consider the following:
Sprint 1 – Team guesses they can get done 5 stories. They get 2 done.
Sprint 2 – Team pulls in 2 stories. They get done 4.
Sprint 3 – Team pulls in 3 stories (average throughput). They get done 5.
Sprint 4 – Team pulls in 3 stories. They get done 5.
Sprint 5 – Team pulls in 4 stories. They get done 5.
Sprint 6 – Team pulls in 4 stories. They get done 5.
Hopefully you see where I’m going with this. If the team simply pulls in their average throughput then there are no guesses required. Plus if they are improving you will see that by virtue of the fact that they are bringing in stretch targets during the Sprint.
AND, Little’s Law tells us that because they are pulling in less than their throughput when their throughput is not a whole number (e.g. in Sprint 6 they can’t pull in 4.2 stories so they pull in 4), they are reducing WIP which is consequently reducing story cycle times. Throughput is also likely to go up with this practice (due to better collaboration/swarming on stories ==> better effectiveness) so everyone’s a winner!
Thanks Renee. Yes, if you have previous projects on which to base predictions then even less reason to estimate!