Friday, 11 November 2011

Quick backlog estimation

One thing that's been really painful in my previous experience is overall backlog estimation. This is often asked for by the business owner as an impact assessment or to try and gain an understanding of roughly how long is a chunk of work going to take.

The issue is when the chunk of work is split into hundreds of smaller chunks of work each of them requiring a fair amount of analysis and design and perhaps UX, etc. in order for the estimate to have any reasonable meaning. Teams often aren't allowed this time while the need for sizing of the chunk of work still remains and could be important to the business.

Over the past few months we have used an approach to fast backlog estimation which combined with follow up prioritization session (I will post about this in another blog post) has resulted in acceptable outcome for both sides. In order for this to work  it is useful if your team has achieved good level of common understanding about estimation of requirements and your backlog should contain a list of user stories and (almost unavoidably a list of epics).

Start with User Stories

Prepare by printing all your user stories (I'd print them all and not use any existing index cards) and have a big table available for the session. Ideally ask 2 dev pairs (or may be 3 devs and a QA) to join you. Separate user stories from epics and work with the user stories first. Separate the cards into 2 piles and give each pair of team members one pile. Ask each pair to work in one half of the table so they don't mix cards (for now). Also ask them to put the user stories in groups by size - e.g. in the middle of the table user stories that seem to be about the average size of a typical story (Group A) , at the top user stories that seem much bigger than average (e.g. 2x or 3x) (Group B) and at the bottom user stories that seem very simple (e.g. 1/2 or 1/3 the average) (Group C) . After this phase is done ask the pairs to switch sides of the table and review what the other pair has done and mark any cards that they may not agree with the suggested sizing for discussion. Have the discussions and move the cards as appropriate if that's what team members agree. You can also have a 4th group of cards (Group D) for stories that have so many unknowns that it seems impossible to put into any of the other groups. Once this phase is done make sure to carefully collect your cards in groups so you can update them later on.

Now the epics

Following a similar approach hand each pair about half of your epic cards and ask them to group them in the following groups. For example in the middle of the table - those for which is  relatively clear what needs doing but it just seems like a lot to do (Group E) , those that seem relatively small at the bottom of the table (Group F) and those that seem fairly unclear or there are lots of unknowns put at the top (Group G). Again ask the two pairs to work in separate half of the tables and then swap to review their groupings. Once this is done thank the team members for their participation and with all collected cards proceed with updating your actual cards in excel or the electronic tool that you're using.

This should take you between 25 and 40 minutes depending on your backlog size. We have consistently achieved below 30 minutes with backlogs of around 80-150 items.

Getting to numbers

Now this will depend on your specific team estimates. I'll take an example where the average size of a story for you might be 5. Note - any stories estimated by the whole team in your usual estimation workshops leave as they are - you can use them to calculate your story average. For any stories without estimates you can do the following: Assign this to group A cards, to group B cards assign 3 times your average size - which would be 15 or perhaps 13 if you're using Fibonacci numbers. To group C stories assign estimate of 2. To Group D items assign 20s and  give to your BA/PO for further analysis - somehow indicate this in your electronic tool. There's two approaches you may want to use for the epics.  Either look at them as gaps of missing stories and ask your BA/PO to estimate how many stories approximately (and as a range) s/he thinks they may contain and use the average story size - e.g. Gap A is likely to produce 5-8 stories so I'd use the higher estimate of 8 and multiply it by my average of 5 which means that Gap A will have size of 40 for the time being.
Or if your BA/PO is not comfortable to do this for now use similar approach to stories e.g. - to Group E assign 3 times the group B estimate - e.g. 40, to group F assign the group B estimate - e.g. 13 and to group F items give something like 2x your group E estimate - e.g. 80 or 100.

Backlog size

Now once you've done all the updating your total backlog size will probably look enormous. Obviously the more epics you have the bigger number you'll get. Explain to your BA/PO that the epics need clarifications and that you'd need these resolved, questions answered and sizes refined before having a meaningful backlog size. Your BA is likely to start analyzing all over the place so why not start with these big items alongside any risky items s/he might be looking at. You could also review the remaining unanswered questions and gaps on a weekly basis reiterating that the sooner you refine those estimates the sooner you can get to a realistic size.


Interesting enough having epics in the backlog has not stopped us doing prioritization sessions with business owners - I will explain how in another blog post.


Once you agree that your backlog seems to contain mostly stuff with known size then you can follow standard burn down/up practices to produce that much desired date/range. I'd also monitor historically what is the growth of the size of a backlog and apply that as a buffer because new stories will get produced. Ideally you'd want to have this growth historic figure based on a full release cycle.

So this one has already  become bigger than I was hoping it will be. I hope it is useful and makes sense. I will try to take a picture next time we do this and attach it here. All feedback is welcome ;)

Thursday, 10 November 2011

One week is just right

This goal of this post is to outline some good reasons why one week iterations are a very good idea for most software development teams.
The suggestions and conclusions below are based on my experience with one week iterations across 3 teams on a major e-commerce project.
Before seeing one week iterations in action I believed they could be too stressful and with very little time to prepare requirements or even complete something useful and potentially end up with nothing to demo most of the weeks. I have since changed my opinion based on almost 50 iterations of evidence so let's start with the reasons

1. It is tough! What I thought before turned out to be true! There are so many things that need to happen for a week and yes it is tough. It is tough for the analysts to prepare requirements, meet with QA and refine them, meet with devs and refine them, get answers and slice and descope as necessary. It is tough for the devs to ensure requirements are small enough to develop and meaningful enough to present, reject requirements that aren't ready, estimate and tech design and implement those that are. It is tough for the QAs to participate in acceptance test specification for new requirements, acceptance test writing for those in progress, functional and journey tests, exploration tests and demo preparations. You get it I believe. Yet even though it is tough it is also very useful that it is tough because it is a built-in pressure that ensures people switch on to disciplined mode because to get through all these you have to be disciplined. So reason number one is that the busy schedule increases discipline and discipline is the best friend of competence.

2. There is stuff to demo! - with over 50 iterations of evidence I am confident one week iterations will not impact teams ability to show progress. Quite the opposite, the ability to show something that isn't just working but actually in most cases ready to go into production is the best way to win the customer over and over again. You could say in most companies the stakeholders would be amazed if you are able to deliver quality meaningful features every week.

3. You really are more agile/flexible. Actually seeing the impact of one week iterations I am starting to think that anything more than 2 really isn't much help in terms of flexibility. Shorter cycles let you fail faster and improve faster. They also allow the business to adapt faster and significantly reduce any change concerns. Shorter cycles also enforce good engineering practices like emerging design and architecture, continuous integration and deployment, true shared code ownership and refactoring.

4. These guys are great! Even though I already touched on credibility in point 2 I think it deserves a separate section. Your ability to deliver every week will impress people, especially if you're the first team in the organisation to do such short cycles. Along with your CI tools and your ability to deploy anytime and I am sure these will prompt even more amazing practices and tools it is very likely that you soon will become centre of attention and people would want to associate themselves with your team and even work for you. Granted this may happen without one week iterations but I believe they improve your chances.

5. It is all or nothing. If you've ever heard a business owner saying "they're all must haves really" then you know what I mean. What one week iterations combine well is positive feeling about delivering all the time and a shorter release planning cycle. And in case you're wondering yes I do mean looking at the release plan with the business owner every week or as often as possible but never more than 2 weeks between the sessions. The combination of high business confidence in your ability to deliver with the regular realisation what is possible with the current capacity and what not will virtually ensure the business owner's buy in into fixed date/flexible scope idea. (I would not really want to go for fixed scope/flexible date but that is for another article).  And that is one of the most important hurdles to making your release successful simply gone.

So in conclusion - I believe one week iterations are just right. Of course based on the environments that I've seen but also based on feedback from 20+ colleagues about the environments that they've seen.
So I'd say it is a pretty good bet that it would help you if you're thinking about doing shorter cycles. And I hope you won't forget to have fun ;)



There was an error in this gadget