11/04/2016
in Methods
How about a new agile approach?
Table of Contents
#NoEstimates is a lean and agile methodology that focuses on the delivery of customer value. To reach this goal it tries to minimize non-value-creating actions like the estimation of implementation effort for User Stories. In the first part we introduced the basic ideas of the methodology. In this part we want to provide some tips on how you can get started with #NoEstimates.
If you want to use #NoEstimates there are 3 fields you should work on: Your estimations, your user stories and features as well as the data you gather.
Estimations
Use Story Points
Depending on how you currently work, moving towards #NoEstimates is a process that consists of several steps. The first step you can take is to use story point for your estimations instead of time-based estimations. This more abstracted way of estimating allows you to better take things link risks, dependencies and complexity into account. Above that it already helps you to reduce discussions about the estimation, because you compare stories with other stories and you’re not discussing a certain amount of time.
Stop Estimating Tasks
Don’t estimate time for each task after you estimated a story, split it into tasks, and then check whether the sum of the tasks matches the time you had estimated for the complete story. That simply creates a lot of work and doesn’t provide value. You will see the progress during the implementation by asking the team “Are we progressing well?” or “Can we complete the story in time?”
Reduction of Estimations
In Scrum or some other agile methodologies you normally start each Sprint with a Sprint Planning where the team estimates the size of User Stories by using Planning Poker. A way to accelerate the estimation process and to move towards #NoEstimates is to reduce the available cards in the Planning Poker deck.
Instead of 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100 you can start to distinguish only 1, 5, 13 and 40 – or small, medium, large and too large. This reduces the discussions whether a User Story has e.g. 2 or 3 points. Over time you can further reduce the number of options until there is no more estimation required. This leads to the second aspect of #NoEstimates.
User Stories and Features
Write Smaller User Stories
Normally a feature consists of several User Stories. #NoEstimates works best if you write User Stories that all have about the same size and that are rather small. This way you can easily see whether a feature is bigger or smaller than another one, based on the number of stories.
In addition to that, the size of user stories should depend on your reporting cycles, because you can use them to report the progress of the implementation. If you have daily reports, e.g. in small projects, your stories should be smaller than 1 day. If you report every 2 weeks, stories can take up to several days, so that you can complete several Stories per iteration. The important thing is that they should have a size that makes them easily accessible in terms of risk, complexity, dependencies and so on.
If you want to learn more about how to write and slize User Stories, you should take a look at this post from our partner blog. It explains the idea of User Stories in more detail.
Limit overall Duration for Features and Stories
A great method to concentrate on customer value is to limit the overall implementation duration for features and their stories. Doing so helps you to write your stories in a manner that they are all about the same size, because you get a feeling on how much can be accomplished within a fixed duration. Beyond that, it supports a culture of prioritization, because every time a story can’t be completed you need to evaluate whether the missing aspects are important or not. This method has 3 major advantages:
- It improves the forecast of the implementation of features, because there’s a fixed length for each story.
- It helps you to focus on the most important features and to take care of missing details when the time is right.
- When a feature isn’t completed in time you learned about it and you can use this knowledge to write the new feature.
Another positive effect of a fixed implementation length is “Parkinson’s Law”. It says that work always expand to use all the time allocated to it. That means that if you estimate a feature to take 4 weeks, then it’s very likely that it will take 4 weeks, or more. If you have a fixed implementation time of 2 weeks, you might be able to say, after those 2 weeks, that it will take another week to finish the work, because your knowledge about the feature is much better than at the time you would have estimated it. This way you would have already won 1 week.
Gather Data and Use It
Measure Duration
Keep track on how long it takes to implement stories and features and build e.g. histograms that show how long the implementation of stories took.
Using this data you can derive your average implementation time and you can use it for forecasts.
Practice Forecasts
Start with small projects to use #NoEstimates and gain experience. Gather data so that you can forecast completion time. At the beginning you might have different sized features (small, medium, large), use the measured implementation times to forecast the completion of the project.
Finally
Everything will fall into place. Once you’re able to proof that your forecast is as accurate as estimations, or even more accurate, you’re in the perfect situation to pull up with #NoEstimates. You can further reduce distinguished feature and story sizes and move towards a continuous development. If you feel like you don’t need Sprint Plannings anymore, you can stop using them. Examine your software development process and concentrate on things that produce customer value.
Modify other agile approaches to get there
If you currently use Scrum you can make a few modifications to your development methodology to increase your efficiency. You can shorten your Sprint Plannings by reducing the available choices step by step. In addition to that, you can start to slice your User Stories into smaller, same sized pieces to further decrease the time for estimations. In the next post we will discuss whether #NoEstimates is applicable in the real world, or not.
