Article summary
My current project looks straightforward from the outside. The client has a mobile app implemented as separate native Android and iOS apps. The engagement is to reskin the app to fit a subtly different end-use case. The client also came with a thoughtful roadmap document enumerating the changes they wanted, and this was easy to break down into a manageable backlog.
Background
A month or so into the engagement, we came across a story that took much longer than our original estimate suggested. This experience made us suspicious of the rest of the backlog. We were left unsure if we would be able to deliver the feature set the client was expecting within their timeline. We also wondered if there were other patches of time-consuming quicksand waiting for us.
Clarity
We could have plowed ahead, picking up stories and letting that anxiety build up. Instead, we opted to block out a chunk of time for a technical review to reevaluate the backlog. We gave ourselves time to evaluate each story and even dig into the code to add specific technical details. Six weeks of development time can work wonders for establishing project context. Our second pass through the stories we had laid out revealed gaps that needed filling with new stories. We also found stories that were no longer relevant and stories that needed tweaking and more technical refinement.
Takeaway: Don’t be afraid to reevaluate the backlog.
Fortunately, we didn’t discover a catastrophe in progress. We came out of the meeting confident about our progress and with a clear path toward the client’s goals. It was a big weight off of my mind knowing that there was no lightning sand or other terrors of the fire swamp lurking ahead of us in the backlog. The exercise helped us clearly articulate what we needed from the client to manage the remaining scope. By taking some time away from the keyboard, we freed up the team’s mental capacity to do great work.