Depending on where you’ve worked as a developer, your agile experience can be radically different than somebody else’s. But one thing you’ve likely always experienced is working out of a shared team backlog. However, it’s one thing to be the one grabbing tasks from a backlog, and another thing to be the person writing those backlog stories. I’ve found that for developers who have plenty of experience with the former, that experience doesn’t necessarily translate well into doing the latter.
After some time writing tasks and working with other developers who do, I’ve observed a few common but correctable mistakes. Here are a few of the things I try to keep in mind so that I’m a better author of backlog stories.
Include more context.
When writing stories for a backlog, especially as a tech lead or senior developer, it’s easy to fall into a habit of writing the story in a way that would enable you to do it personally. After all, we usually are also at least part of the audience for whom we’re writing. However, we can accidentally leave out important details that would otherwise enable other team members to work on a story.
As a simple example, say I’m involved in high-level meetings about my team’s app. It’s decided that some text color on a particular page needs to be changed to be more readable. I can write a simple task with a description like “On Page X, change the font color to dark gray instead of black.”
For such a simple task, this may be sufficient. Somebody could easily grab it from the backlog and likely complete it. However, the developer doing the task may not have all the same context as I do. If they knew it was for readability, while they work they could keep an eye out for other parts of the app that need the same change, and were maybe missed in my meeting discussing it.
This is a small difference between my understanding of the task and the developer doing the task, but closing that gap could avoid future work to fix something they might have otherwise noticed. “Page X currently doesn’t meet our standards for readability. On Page X, change the font color to dark gray instead of black” only adds one sentence to the description, but it clues your team into the reasoning behind a story and enables them to consider that context as they work.
Provide Resources and Examples
It’s likely that in writing a task, you’ve had to research it yourself. That might be understanding a certain library, talking to certain stakeholders, or learning how another team in your organization did a similar task. I’ve often forgotten that this pre-work for tasks in the backlog can be a valuable resource for the developer doing the work. To remedy this, I’ve tried to make it a habit to include as much of this information in the stories I’m writing as I can. Often what does the trick is as simple as including a list of links relevant to a task.
Sites with documentation, notes about another team’s implementation of the same feature with a link to their code, and names of stakeholders who can be asked about certain parts of the task. It’s fine to have faith in your team that they can find these things on their own, but I’ve found that it saves everyone on the team time when you just provide all of those resources from the start. There’s less back and forth between the story author and the developer of the story about who to ask which questions. And, developers save time Googling or combing through your organization’s Slack or other codebases to find relevant examples themselves.
Clarify your acceptance criteria.
In my experience, the number one most important part of a task is the acceptance criteria. This is certainly not a hot take by any means, but knowing how to write good AC is different than actually writing good AC. A developer needs to know what makes their task considered “done.”
Especially on smaller projects, perhaps with less formal backlogs, it’s easy to just treat story descriptions as acceptance criteria. In practice, though, this tends to expose a disconnect between the story author’s expectations and the developer’s. Perhaps I know that for a task about implementing a new API endpoint, there needs to be logging at particular steps in the workflow. But if somebody new to the team or their career is responsible for accomplishing a task that just describes what the endpoint itself should do, they’d likely miss that.
Providing additional, clearer AC for a task enables you to dictate certain decisions that otherwise the developer picking up the task would have to decide on their own, or brings to their attention minor details that wouldn’t be relevant to a more user or business-focused description for the story itself.
In short, I’ve found that writing tasks for myself is entirely different from writing tasks for a team of other developers. But, with some additional effort when writing them, I can help my team avoid friction when there’s a lack of understanding of what they need to do. The three tips above can be a good place to start when evaluating yourself as an author of stories, but they aren’t exhaustive. I think, ultimately, the best way to be a better author of your backlog is to work closely with the ones picking up the tasks, solicit their feedback, and continue to make improvements to suit your team.