Photo by Christina @ wocintechchat.com on Unsplash

If we want to help the team to work better together and build a higher quality product, we need to also see if the team has any bottlenecks in their work ways. Depending on the methodology the team is embracing, they may build their work around certain work items, methods, and rituals. Before we dig deeper into boards and workflow itself, we need to start exploring what work items we have, and, if they are of the right quality. We will speak later on in this Quality Foundations series about requirement analysis in more depth, but prior to that we need to be on the same page with some definitions.

How is the team tracking their work? Do they have cards for what they’re doing? What work item types do they have? The most common tool used to track work items is JIRA, yet some teams use different tools or even prefer a physical board to track their progress.

One of the first discussions in a newly formed team is to agree on conventions and what is what: what do we mean when we say there’s a spike or a user story? Also, how do we create work items? What should the work item include in order to be considered ready to be worked on?

In this post, I will explain the most common work items I have seen teams work with and include simplified examples. I will start with some tips on how they could be structured. After that, I’ll dive into what works item types there are. Finally, I’ll shortly touch on work item management.

Do’s and don’ts for structure of work items

All work items should be defined based on a certain guideline. I believe having a clear structure can help us avoid misunderstandings. How we provide the needed for work information is a beginning of any work - it is important to make sure it’s detailed, yet concise.

Do include in all of your work items:

Context

Why are we working on this item? What do the main business terms in this story represent? A short description is always useful, but if there are longer sources for business context - feel free to link them to the work item in the links section, do not just paste a link to the story (see avoids).

Acceptance criteria/to-do

What has to be done for this work item to be considered complete?

Better more information than less

What is needed when working on this card? Is there any dependency? Who would be the contact if the developer had any questions? Do we have everything clarified? Any useful notes? We should avoid assumptions that everyone knows the domain/topic. Overcommunicate (yet not too much, we need to balance this as well).

Avoid having work items include:

Vague descriptions

“We should make it compliant” -> what does compliant mean in this case? There are many interpretations, so avoid vague words/terms that need some extra knowledge.

Links to chat/other work items

I have seen work items where all that the description had was a URL to the chat conversation. That is extremely difficult to work with, and does not help the person working on the item at all. On a similar note, the criteria of what makes the work item complete should not link to a different work item. Keep the information condensed and clear in one spot. People may assume they know and even skip opening the URL.

Checklists/reminders in description that get pasted to each work item

I have seen some work item templates always including huge lists of acceptance tests or checklists for checking which in the end just pollute the whole description creating lots of noise that gets ignored. Questions are extremely helpful, reminders as well, yet they should be a part of work rituals rather than of work item descriptions.

Work item types

There are 4 work item types that I’ve seen the teams work the most with: spike, user story, (tech) task and bug.

User story

Most of the teams know what a user story is: it’s usually feature work which is written from a user’s perspective. It’s important to be specific enough on who the user is and why they need a certain feature.

I have seen teams write the usual “As a …, I want to …, so that …” in either title or even as acceptance criteria. I think any can work as long as it expresses what should be done. Often when formulating acceptance criteria, I feel it’s helpful to use “When/then” structure.

To aid writing better stories, there are some checklists like INVEST which remind us that a good story should be: Independent, Negotiable, Valuable (or Vertical), Estimable, Small, and Testable. Apart from that, if you keep adding similar acceptance criteria items for multiple stories, another type of checklists could help like a “dev-done” list. For example, in some teams I’ve seen a repeating acceptance criteria: “When we click on this feature, there’s a log recorded as well”. This could be a part of a reminder for each story in a form of a separate list to go through in the story lifecycle. I will touch on that later on in the Quality Foundations series.

A simplified example of a user story

Spike

The term spike comes from Extreme Programming (XP) practices and was coined by Kent Beck. Spike is a task which aims to answer a certain question in a timeboxed manner. Spikes can help us gain more knowledge about work to be done and reduce uncertainty.

For example, if we are not sure what technology we should use for a certain task we’re about to implement - we could create a spike to try out the main candidate for a day. If after a day we are confident that this technology does seem to serve a needed purpose, it strengthens our decision to use that technology and we can proceed doing the task with more clarity. If this actually does not work, then we may need to research the area a bit more in order to be able to continue with the task.

I am strongly for timeboxing spikes because of its exploratory nature: we may get carried away with research and experiments. Spike is just getting a glimpse on what could actually be implemented. Often I would include as a success criteria for the spike the creation of follow up tasks. Those can continue the work of the spike in a more organized manner.

It may as well happen that a spike becomes a proof of concept which is a must-do before story implementation. In that case I’d still try to timebox just for the sake of transparency, yet the timebox may be pretty long (max a week I’d say) and there may be cases when it’s not possible or it explodes a bit - it’s alright as long as the team communicates openly why it happened.

A simplified example of a spike

Task

Often I see tasks used in the context of “tech” tasks. I believe that tasks could be not only that. The difference between a user story and a task would be that it may not provide as much of user value, yet it is necessary for the team’s work. For example, a task could be cleaning up a feature toggle, improving functionality, or even onboarding/offboarding a team member if we agree to visualize work like that.

A simplified example of a task

Bug

Here we are in my favorite categories of buggos 🐞 as I like to call them. A well-written bug is a must in order to save time trying to understand and debug it. It has to include clear steps to reproduce and any information that could be useful in fixing.

A simplified example of a bug

Work item management

What about smaller tasks that may come up? For example, helping a team you’re integrating with to develop. Should they be created and reflected on the work items backlog/board? I’d prefer them to be visualised, so the team does know what work is approaching or we’re spending the time on. Same goes with tech debt items or suggested improvements - it’s great to have the work seen and that can guide our prioritization conversations.

When we discover some bits and pieces we want to improve, we may lose track that it is actually an extra task we’re overtaking. For that reason, if we create a card and communicate to the team, we can see if it’s worth the trade-offs tackling it right now or better to do it later on. We can compromise on what makes sense to be worked on now.

When it comes to the backlogs - the lists of work items - I really think we need to keep them clean. It’s very common to gather quite a lot of clutter there in case we had lots of great ideas and never got to them. Regularly taking a look at the backlog and closing or reprioritizing items can make the team way more effective.

In the following Quality Foundations posts I will go more in depth on story lifecycle, work board, artifacts, rituals, and much more.