Lately I’ve been thinking a lot about User Story estimation. It all started with the idea to put more focus on quality and unit test coverage. That led me to realize that there are often times where technical practices like code refactoring, code cleanup, and even unit tests are left behind in favor of getting the story done by the end of the sprint (usually in the quickest way possible). There’s often a mentality that “we’ll come back to that later so let’s just do what we need to do to produce the Potentially Shippable Increment” or “we’ll put a story on the backlog to come back to that (which stays at the bottom of the backlog)”. That feeling is the indicator that you’re part of a feature factory.
Periodically, it helps to remind ourselves of what all should be included in story estimates.
A user story estimate is a point value assigned to that user story based on how much effort it will take to get the story done according to your team’s definition of done. There are a few other factors like complexity and unknowns but let’s keep things simple for this discussion. Teams should be including things like unit testing as part of their definition of done in some way or another. However, as developers, sometimes we still tend to estimate like we’re playing golf and trying to get the lowest value possible. The question we often ask ourselves is “What’s the quickest time frame I can get this done in?”. We get this badass, superhero mentality.
“You think we can’t do that user story in 2 points?”
“Never tell me the odds!”
Getting a story to done as fast as we can or saving a few points in the estimate won’t help us when we’re troubleshooting a production incident because we missed a few unit tests for edge cases.
So how should we estimate?
What should we change?
This takes me back to “Uncle Bob” Martin’s Clean Code and Clean Coder books where he often refers to developers as “craftsman”. As craftsmen, we should have high standards for our work. We need to be willing to say that we can’t push a feature to production because it doesn’t have enough unit tests or because the code isn’t as efficient as it should be or because there’s a small chance we are introducing a bug. In his latest book in the series, Clean Agile, he states that engineers should never need to ask for permission to do things like unit tests.
With that in mind, as craftsmen, we should be sure we’re including the following in our user story estimates. Most of you will already be factoring some or all of these into your estimates, so treat this as a friendly reminder.
1. Effort for Quality
Hopefully this one is common sense and hopefully you’re already including all forms of testing in your estimation thought process. However, if you’re not doing TDD (Test-Driven Development), it’s always good to be reminded to include the time and effort it takes to ensure unit test coverage in your estimates. Don’t forget about any other testing that is needed like writing automation tests or conducting performance tests. Some user stories are uniquely complex and may have an unusually high amount of unit test scenarios. This should be pointed out in planning and estimated accordingly.
If unit tests aren’t in your DoD, go add it right now.
2. Effort to Refactor Code
The best way to minimize technical debt is to constantly chip away at it. I’m a big fan of the Boy Scout rule: Always leave the code cleaner then when you found it. As developers, we’re dealing with the same code constantly. We get a feel for which parts of it could benefit from some refactoring. If we’re grooming a user story and we know we’ll be making changes to one of those bits of code, why not factor in the time and effort it will take to refactor or clean up that class or file?
If you refactor a bit of code, be sure to no-break test it as part of testing the User Story. Ideally your test suite would cover this.
3. Effort of the Right Way vs the Quick Way
We’ve all been in the situation where our Product Owner is pushing to get things done quick and we weigh the pros and cons of doing things the quick way vs the right way. We’ve all been guilty of taking the quick way before, justifying it with an agreement that “we’ll come back and refactor it later”. In reality, most of the time we never come back to it. Instead of settling for the quick way, this is your chance to fight for the right way. Doing so will minimize your technical debt and, in most cases, result in increased scalability and reliability.
The bottom line is that you aren’t just estimating the amount of effort it will take to deliver software. You should be estimating the amount of effort it will take to deliver high-quality, well-tested, software that you’re comfortable and confident putting in the hands of your users. Remember, Agile and Scrum encourage teams to work at a sustainable pace to deliver quality, working software. Don’t aim for the lowest estimate, aim for the right estimate to deliver world-class solutions. Hopefully this isn’t news to you and hopefully you read parts of this and though “duh”, but we could all benefit from a friendly reminder from time to time.
Further Reading: Many of these ideas echo the concept of Flaccid Scrum which states that implementing the business side of agile will only get you so far and will even slow you down if you don’t also focus on the technical practices.
Have you experienced similar issues?
Let me know in the comments below!