In this Quality Foundations post, I’ll share basics with examples on story life cycle, work boards, and ways of working. Also, I’ll explain why all this matters if we want to build high-quality products.

When I was applying for my first ever testing position, the interviewer asked me: “What is a software development cycle?”. I was a bit puzzled, I was not sure what they meant. What the interviewer was really getting to was if I knew about software development workflow, and how I’d imagine work states change. Shrugging my shoulders at that question, I came home and googled to discover that it’s just a process for planning, designing and developing the product that sometimes is shortened to SDLC.

There are different names/terms for it, some explain the same process parts as the product life cycle. If we try to ship smaller blocks and use a methodology like Agile, we may want to talk about smaller work items. This is why story lifecycle is a great way to track work in teams, establish processes, and follow how work progresses.

What is a story life cycle?

For the simplicity I’ll say “story life cycle” here and address it using the user story as a work item. Yet, other work items as well go through this life cycle.

Story life cycle is a process of… story’s life. From story analysis on what it has to actually do, development, growth, and then release into the world (which may be: going live or release to production). There are stages before and after this: the ideation process of the story or maintenance of released work.

In this Quality Foundations post, when I talk about the story lifecycle I want to concentrate more on the parts we can see, the parts we visualize in our work boards. Let’s take the story life cycle from analysis to done.

Why does it matter for quality of work?

“Alright, Lina, what is this theoretical stuff? How does this help up the quality game???”. I hear you!

Your work board which visualizes your story life cycle is representing your ways of work. If there are unnecessary or chaotic parts, then it’s easy to make mistakes and stumble into bottlenecks. There are lots of helpers that we can use to make the story life cycle smoother, better supported, and as a result - work can become more efficient, collaborative and of higher quality.

As a QA joining a new team, the work board is the first thing I want to see. How do people work? Are there any areas that we forget and how could we improve the process? Having a well-defined way of working helps us to deliver not only better quality, but also deliver faster, although for some people this sounds like an oxymoron when we talk about high-quality products.

What does your work board look like?

When considering any board, these questions come to my mind:

• What does your work board look like?
• When does one item move to another state?
• What methodology do you follow?

Let me start with an example. A team I joined had a JIRA board to visualize their work items. That board had 10 (!) columns: Refinement, Waiting room, Ready for pickup, Development, Ready for QA, In QA, Blocked, Sign off, Done, and Showcase. The team was used to this board. It was a little too much and hard to grasp how work actually flows in this structure. Despite embracing the idea of doing desk checks and other helpful means of collaboration like story kick offs, the team did not have a habit of putting them into practice regularly. There was information, maybe sometimes even too much of it, yet the team lacked clearer guidance, knowledge sharing, and forgot to tackle some tasks which improved the quality and maintenance of their work due to the lack of collaboration. It was time for a change.

It’s a team conversation

It’s hard to change what is already there and maybe… always has been there. Maybe we took that JIRA board as it was from day 1 without questioning it. And very likely we are used to certain habits of how the work flows.

If we want team accountability on quality, we need to have team involvement in discussing the ways of collaboration.

In the team mentioned above with 10 columns, even if I had an idea of my “ideal” board and ways of working, I did not just bring it and say: “From today, we work in this way!”. This, in some cases, could work, yet I also wanted to learn more about the current board and people’s needs for information flow. Work board’s goal is information sharing - if we’re removing some columns, we need to make sure that the information we had there is still reflected and not missing. It may mean that we need to add extra comments instead. All members of the team have to align on that. Also, the alignment creates a shared sense of accountability to follow the new process.

How to effectively facilitate a story lifecycle conversation?

When we wanted to readjust our story lifecycle, we arranged a 2-hour workshop to discuss the status quo and what improvements we could make. We collected pain points and what limitations current work ways introduced. Also, we took a look at each column and tried to clarify what it means to us, who are the actors (what team member roles are involved there), when the story moves to/from that column, if that column reflects the priorities, and if the work item could jump over that column without ever being there.

After the status quo discussion, we jumped into talking about what a dream board could look like. When we talk about this, there are some aspects to keep in mind:

• Actors: what roles do we have in the team and how do they act within the story life cycle? For example, Product Owners may be involved in the analysis and sign-off, but nowhere else.
• Columns: what work states do we want to visualize? If we are removing some columns, what information did they have and how will we provide it without having a column? Remember that often a challenge is not a column itself, but unclear responsibilities on who follows up on work there. This is why actors matter, too.
• Rituals/ceremonies: do we do story kick-offs and desk checks? If yes, where do they take place? If not, would it be helpful for the team?
• Artifacts/question lists: What question lists could help us to make sure we’re not forgetting things? Are they well-defined, or the team may need to polish them? For example, story kick-off or desk check question lists, the definition of done, or the definition of ready.

After the initial discussion, we split into groups of around 3-4 people and brainstormed how current pain points could be avoided with a new work board structure and what we need to change with the ways of working. After some time, the groups came back together and presented their ideas. Having all this information in mind, we came up with initial suggestions for a new work board, a clearer story lifecycle, and aligned new ways of working.

To summarize the results of all this and make sure we have clear action items, the facilitators created a summary document where everyone could comment if they had further thoughts. This is also a remote-friendly way to have a conversation.

The easy part is the change of columns in JIRA, the more challenging one is avoiding bottlenecks and involving rituals and more intense collaboration. On the bright side, if all team members discussed the story lifecycle and ways of working, they will more likely be committed to the change together.

Example

I’ve seen all kinds of work boards. What matters are not the columns themselves, it’s the people’s collaboration and ways of working. However, if you have an unclear story lifecycle, it can make everything a bit more fluffy.

The teams I prefer to work in are cross-functional teams formed having a two-pizza rule in mind: it was no more than 10 people so that they could share two pizzas (well, I’d say depends on how hungry you are!). It’s been a while since I worked with another Quality Analyst in the same team: I am used to being the only QA in the team. In this case, we need some new ways of work and share quality accountability better. QA column may not work. This is why all rituals and artifacts can help us to quality assist other roles.

So, what’s an example board from the teams I worked in? It does not have a QA column (and I do talk more about that in desk check post). Also, apart from the usual To Do - In Progress - Done it also has a Clean Up column. This column worked for that particular team as a reminder to clean up feature toggles after the feature went live (and this is exactly what the definition of done could include - that the feature is actually on prod and feature toggles were cleaned up).

Example story lifecycle & work board

Even if this is the work board visualization I’m most used to, I would not stick to it. Context is key and even if for one team this works, for another it may not.

Conclusion

High-performing teams create high-quality products because they have a clear process of their working ways, and they’re also open to improving them based on the lessons they had on the way. Their story life cycle is known to every team member, work boards visualize how work items move forward, and ways of working support collaboration. We need this if we want to have a continuous quality mindset. As Aristotle has said - “Quality is not an act, it’s a habit.”

A summary of steps that can help you improve your story lifecycle:

• Arrange a conversation with the team.
• Understand what information is needed, what information is lacking.
• Remove obsolete columns - less is more sometimes, information can be communicated in other ways. Flags and comments can even provide a more in depth view of the progress.
• Rename columns which are unclear and define who takes responsibility for moving the cards.
• Spread accountability on quality practices.
• Have patience - change takes time. Step by step.
• Revisit the work ways from time to time. Context is key.

In further posts of Quality Foundations I’ll write more about definitions of ready & done, and some other possible improvements for ways of working like retrospectives.