I’ve been on several projects that began with large periods of uncertainty. This uncertainty can come from many different sources but often manifests in the same symptoms:
- A lack of visible progress. That doesn’t mean no progress, but when there are significant technical hurdles, the progress is often under the hood and not visible to customers.
- An incomplete backlog.
- User stories that stay open for weeks at a time.
- Velocity that shifts wildly.
These most often crop up on technically challenging projects where it’s unclear how to solve the problem, so you spend time researching what’s possible and what the existing tools are.
If you find yourself in this situation, here are some things to try.
1. Reestimate your backlog frequently.
It’s common to put a number on a story as an estimate, but it should be clear that not every estimate represents the same amount of confidence. And that’s okay! The backlog isn’t supposed to be a perfect blueprint of your project’s future. Instead, treat it as your best guess of the route you’ll take, and update it as you go.
I’d recommend reestimating all of your stories whenever you have a better idea of their effort. Do it as frequently as you need to — as often as each sprint. Things will move a lot, but you’re learning. The knowledge about what’s easy and hard is very valuable.
2. Write stories that are easy to change.
To make reestimating easier, don’t over-specify your stories. It’s great when you can have a story with a mockup of every screen, but those take time to specify well. Instead, keep them as placeholder stories of just a sentence or three. By keeping the stories light, you make it easy to reshape your backlog as you learn where the boundaries are.
Obviously, when you start working on a story, you should have a clear idea of goals. But when things are changing fast, it’s not worth it to spend time defining next week’s stories. Just figure out the next thing to work on.
3. Write some tests.
When I’m figuring out the shape of an application’s architecture, things can shift quickly. This can make it hard to keep a green test suite, as you find yourself writing tests and then throwing them away soon after.
But I think that’s exactly the wrong approach. As tempting as it can be to go with the flow, it’s much much harder to come in after and fill in some tests. Letting things go at this stage can often mean that you have a core part of your application with no tests.
If you find you really can’t keep up with a complete unit test suite, at least run some full-system integration tests. That will give you some flexibility within the boundaries of the system while still providing some assurance.
4. But mostly, get ready to roll with the changes.
Things change fast when you’re getting started. Take care to write good code, and don’t worry when you throw it away. Write the best plan you can in your backlog, but don’t hesitate to throw it all away when you know better.
Remember, the way to have the best view of the road ahead is to focus on the road ahead. Past wrong turns don’t matter anymore.