It should go without saying, but estimates are by definition (and always will be!) a quantification of risk and effort based on imperfect knowledge. As I’ve mentioned before, in my opinion using estimates in a software project is a delicate balance, and in many teams if the culture is not right can cause far more harm than good. By acknowledging risk and adapting, a team can use this to its advantage, by adjusting their approach based on the estimated complexity of a story.
Many teams like to use “story points”, which are meant to be a numerical scale to describe the relative size of stories that has no link to time. The scale used is often the Fibonacci numbers (1,2,3,5,8,13…). A nice way to drive this in practice is for the team collectively to describe an example of a story that maps to each size. For example, a text change in the UI may be a typical “1”; a new API endpoint may be a typical “3”; a new deployable component that requires build scripting effort may be an “8”. Stories should be compared to historical stories on an ongoing basis to refine these examples, as part of the teams continuous improvement of their process.
One reason that the Fibonacci numbers are chosen to represent stories is that they diverge as they get larger. The intent is to show that as the perceived complexity of a piece of work increases, the accuracy of the estimate goes down. When faced with a large piece of work, the ideal thing to do is to decompose it into smaller pieces of work, to remove some of that risk. For whatever reason though, this isn’t always possible, and the team will be left from time to time with larger stories that they will need to tackle.
To deal with this and smooth the risk, something I’ve seen help teams is to introduce a set of simple rules around how a team tackles stories based on their size:
- Any member of the team can pair on any story
- Any member of the team can request design input or other guidance on any story
- Any story that is a “5” or larger must have a design review before implementation starts
- Any story that is an “8” or larger must be tackled as a pair
Sadly, in many teams who haven’t fully embraced agile delivery mindsets and techniques, pairing can still be seen negatively – “why does it take two people to do that; they could get twice as much done” and so on. One big win from pairing is that it gives a continuous review; there are two people looking at the same problem, and they will naturally “keep each other honest” – the pair have an infinite opportunity at any stage to adjust the direction they are taking or to consider other options, and there will probably be no shortcuts taken. It is well documented that the number of defects that come from pair-developed code is significantly lower, and that when it comes to complex work, pairs will end up being much faster than a single developer in isolation, partly because they form a “driver/navigator” dynamic where one focuses on detail and the other on big picture.
The design reviews that the team hold can be as simple or involved as they find helpful; the rule is simply that before starting implementation, the developer who will do the work must have described the approach they intend to take and got feedback on it. I consistently see that when a story goes off the rails, it is because an individual chose not to seek feedback and chose not to prepare, but instead rushed in. A great outcome of a design review is that the original plan is heavily modified; this means that the review has caught a potential problem before it had the chance to grow! There is no rule saying the team can’t have more than one design session, and sometimes if the original design doesn’t hold up in reality, this can be a very effective way for the team to adapt in-flight.
The first two rules are also really important; they act to discourage a “hero” anti-pattern that can often be seen in developers, where individuals perceive weakness in collaborating and want to show off their individual skills. Mature professionals know that two heads are normally better than one, and that all members of the team can learn from their peers. It’s also much more enjoyable to share knowledge and experiences in a group, and morale tends to be much higher in teams that collaborate effectively. The goal as a team should always be to be “more than the sum of your parts”!
There will inevitably be larger or more complex pieces of work that a team needs to tackle, but by recognizing and reacting to the risk, and by leveraging more of the team’s combined skill, delivering these stories can be much smoother and an enjoyable experience.