Whenever I see discussions of agile workflows I read developers complaining about how it doesn't work. They're constantly pushed to do more and to do it faster. That leads to buggy code and missed deadlines. It also, makes working as a developer miserable. In this series I'm going to talk about some of the things we've done to make using an agile process enjoyable. I don't expect this exact process to work for everyone. However, it does work for my team.
First up is planning a new feature. This involves writing a specification and providing a rough estimate. The purpose of these is to communicate with non-technical people within your company. You need everyone to agree on what you're going to build and to know roughly when it'll be ready.
Writing a Spec
The purpose of writing a spec is to achieve consensus on what is going to be built. It's very helpful to have a complete picture of what you're going to build in one place. It's impossible to make intelligent technical tradeoffs if you don't know what you're going to be building or its constraints.
Don't try to design everything in this initial spec. The purpose is to get a rough idea of what you're going to build and any constraints. For example, if you're designing some dynamic web pages you would want to know:
- What pages will there be?
- What information will be displayed on each page?
- Where will the information come from?
- What actions can be performed on each page?
- Are there any constraints such as a minimum response time?
It's helpful to include the motivation for the project. If you know why you're building something you may be able to think of better ways to solve the problem. Also, include any help you expect to need from others. If you'll need some graphics designed or a new service to be deployed it's best to let those people know as soon as possible.
Finally get all the stakeholders involved to review and sign off on your spec. This allows you to get feedback and clarify the design. Include a representative from every department who will be involved. This might include business, development, QA, OPS, and design.
It's not fun to have to estimate something that's only vaguely defined, but it's often necessary. If someone on the business side wants a new feature they need to know the rough level of effort to know whether it's worth doing. A feature that's a huge win if it takes three months may not be worth doing at all if it takes a year.
A key here is to add plenty of padding to account for the inevitable changes and distractions. It's easy to think about how long something would take if you focused on it exclusively, but that's not realistic. You're going to have meetings, emergency bug fixes, and some features will take longer than expected.
Here's how I might go about putting together an estimate. At first glance I estimate the spec will take two to four weeks to implement. I know it's likely the design will change somewhat as we go so I increase the estimate to six weeks to account for that. I increase it to two months because I expect to get pulled away for something else at least once during the project. I then add an extra month to give some padding even in the worst-case scenario. So, my final estimate is three months.
That might seem like a crazy high estimate to you, but there's a purpose in doing it this way. The goal is not to give an accurate estimate of how long the development alone will take. It's to give your stakeholders an upper bound on how long the project will take to end up in user's hands. This may include design creating assets, development writing the code, QA testing, and OPS deploying the feature. If you're able to do this well the people waiting on your work will be able to confidently plan around the new feature.
Also, if there's some reason that estimate won't work, the best time to discuss that is before you start. Your team may realize that the project isn't worth doing. Or you can discuss what tradeoffs you can make to get done faster. This might include cutting features or pulling in someone else to take some of your usual responsibilities.
It can be difficult to give as long of an estimate as you ought to. However, you'll find that if you're able to consistently hit your estimates that others will love you for it. Also, having a reasonable timeline takes away a lot of the pressure to cut corners. If you keep cutting corners eventually you end up with a mess that makes everything take longer anyway.