Getting started
Lately when I’ve been working, I’ve become much more deliberate with fleshing out details and requirements before starting work on a new card. Maybe it’s because the recent work I’ve done has needed more thought than typical. Maybe it’s because I just picked up a really nice journal. Either way, I’ve really enjoyed the thoughtfulness of it all, and I think I’m producing higher quality work.
As I’ve thought about this more, I think the process is necessary. We often talk about the card as being a “conversation placeholder”, but it can’t really live up to that designation if no conversation ever takes place. As engineers, it’s our responsibility to take a feature requirement and turn it into an actionable implementation.
To get started, put your digital tools aside. While they’re good for many reasons, for this initial step we want to slow down and fully think about the card. This slowdown is intentional. You want to consider all of the requirements, not just the few obvious or stated ones. Open your notebook or journal and start on a new page. List the card number, title, and date. If there is a UI element, make a quick sketch. If you’re making data model changes, sketch out a quick diagram of additions/deletions. If you’re changing how data models interact with one another, sketch a diagram of the new relationships.
Write out each acceptance criteria item, and put an empty checkbox next to it. If the card lacks acceptance criteria, label it as a draft and make educated guesses to what they should be. You really want a good idea of what the end goal of the card is before you start. Good acceptance criteria will describe the goal of the requirement e.g. “user can perform x and the result is persisted”, not a specific implementation “after user performs x, the y is saved in z column”. This is a balancing act between specificity and flexibility. Share your draft acceptance criteria with the product owner and have consensus before continuing further.
Thinking about your implementation
Write down the users expectations. If the requirement involves interface work, list all the interactions available to you and which are possible. This is especially helpful if you’re trailblazing a new part of the application. Stay consistent with UI conventions, but don’t be afraid to propose new interactions if you think it will benefit the user.
Write down how you expect to implement the story and any challenges you thing you might face. You’ll compare your expectation with how it turned out when you’re finished.
It’s time to collaborate! Share your expected implementation with a colleague. Be sure to listen to their feedback and incorporate it into your plan. This is the time to expose any holes in your implementation. Substitute a rubber ducky when no colleagues are available.
Communicating expectations
Now that you’ve really thought through the requirements and how it needs to be implemented you may have questions. Great! Rank your questions. Those that address things that might block you go first. Those that affect your implementation’s inner workings are second. Avoid the pitfall of listing out all the possible branching questions and answers. If your question could have a followup question, only concern yourself with one followup question for now. Allow the conversation to guide any further followup questions. If you have more than a few questions, consider a quick phone call instead of email or chatroom. In my experience a quick 10 minute phone call can save you from spending 45 minutes explaining all the background to your questions.
One great way to avoid misunderstanding later and gain clarity on the card now is to replace any references with values. For example if you see “works like the address form”, add how the address form works right next to it in the description “works like works like the address form (Validates zip, city, and State. User can add or remove addresses.)”.
While you’re developing keep your notebook open, within reach, and with a pen ready. Write down any additional questions or tasks as they come up. It’s good that you’re thinking of questions and improvements while you’re working. To keep up your productivity get tasks for later down on paper and out of your head as quickly as possible and move on.
Sometimes I find it useful to write out my module’s dependencies, and the file paths to each relevant file, especially when I’m working on a section of an application I’m not as familiar with. The main benefit here is having a quick reference to avoid loosing focus from failing to remember what a file was called.
Debrief afterwards to improve your craft
After you’ve finished and your work is accepted go back to your hypothesis and review how things turned out differed from what you thought. Write down the differences with how you might improve your hypothesis or work in the future. Remember the only difference between screwing around and science is writing it down. By reviewing your original hypothesis again at the end, hopefully you can gain insight into how how you work, estimate, and plan.
A Guide to Estimation and Velocity
If you are feeling the pressure of hitting a deadline or accurately estimating your budget, this free guide can help you.
