DEV Community: Nick Scheynen 🇧🇪

A guide to backlog refinement for agile scrum teams

Nick Scheynen 🇧🇪 — Wed, 09 Mar 2022 16:52:10 +0000

What is backlog grooming or backlog refinement?

Backlog refinement, also referred to as backlog grooming, is the practice of clarifying and creating a shared understanding of both the business requirements as well as implementation details of a piece of software ahead of its implementation. In this article, we'll first clarify some of the key terminology and motives behind backlog grooming. Afterwards, we'll provide some practical tips that can help agile teams run better refinement meetings.

What's a product backlog?

Before clarifying why backlog refinement is important, let's define what needs refinement. A product backlog is a prioritised list of idea's or tasks that an agile team can choose to execute or implement with the goal of improving their software. Most common types of such improvement are the following:

User story: describes a new feature from the eyes of the end user
Bug report: describes how an existing feature did not work as expected
Spike: describes something the team wants to learn more about or experiment with before making a bigger implementation decision.
Task: anything else, from running a post-deployment script to writing feature documentation.

Of course, it's not a coincidence that those are also the most common issue types in Jira.

As said above, a product backlog is a prioritised list where the highest priority items are positioned at the top. This makes it easy for the agile team to decide what to implement next. Backlog items can derive their priority from multiple sources for example a bug that breaks the software for many users should probably be fixed as soon as possible. At the same time, a spike blocking an important implementation decision about a feature with a tight deadline could be equally important.

Next, let's define what exactly is backlog refinement and why it's important.

Why do agile teams refine their backlogs?

As briefly described in the introduction, backlog grooming is a practice that serves two main purposes in agile teams. First and foremost, it helps the team clarify the exact requirements of the backlog items. Clarifying can mean multiple things. It could be the product owner explaining the business reason behind a new feature, but it can also be a back-end engineer asking his colleagues about how to technically implement the requirements. The former is useful, because it gives the whole team an opportunity to contribute to how the product evolves to achieve its business goals. The latter is valuable because it gives the whole team a chance to contribute to implementation trade-offs.

Given the wide range of questions that might come up, when is a ticket clear enough? To answer this question, it's important to know that before planning a backlog item into a sprint, it needs an estimation. While some agile teams split the practice of refinement and estimation in separate rituals, the goal of refinement should be for the team to reliably estimate the time/effort/complexity of implementing the backlog item. Because of this, personally, I don't believe it makes sense to separate grooming and estimation, as big differences in estimation of the same item across the team often spark the most useful discussions to clarify implementation strategy.
It's common that during backlog grooming, some questions come up that cannot be answered right away and therefore it can take multiple refinement iterations before the item can be estimated.

The second purpose of backlog grooming is to ensure the clarified requirements are shared amongst all members of the team. This is important for the team to be resilient against members leaving, regardless if temporary or forever, by having other team members take over their tasks.

Practical tips for running a backlog grooming meeting

Tip 1: Prepare for the meeting

Product Owner

As a product owner, to prepare for the backlog refinement meeting, do the following things:

Ensure the tickets you want to discuss contain all details you have at the moment. Don't hesitate to be explicit about currently still open questions either.
Make a list of items that you want to discuss with the team and put them in order of importance.
Share the list of tickets that you want to discuss with the team a day or two in advance.

Engineers and other team members

As an engineer or other team member, to prepare for the backlog refinement meeting, do the following things:

Go through the list of tickets shared by the product owner ahead of the meeting, think about how you'd go about the implementation and write any questions that come up in the comments.

Tip 2: Be aware of getting stuck in the rabbit hole

As discussed before, many questions can come up while refining backlog items and it might take multiple iterations for the team to feel confident about estimating an item reliably. Therefore, the discussion around one item can take over the whole meeting without even leading to an estimation. To prevent this, during the meeting, keep an eye on both the agenda with items for refinement as well as the time in order to time box certain discussions. When cutting a discussion short, make sure to agree on next steps. This could be a list of questions that need to be answered before discussing further, or a new spike item to be taken into the next sprint to evaluate different implementation strategies.

Tip 3: Update the ticket descriptions during the meeting

While the team discusses questions and implementation options, make sure to update the ticket description with open questions that still need to be answered, as well as decisions commonly taken around the implementation strategy.

Tip 4: Promote discussion during the meeting

Where the refinement of certain backlog items might lead the team to get stuck in the rabbit hole, other items might spark almost no reaction or discussion. This might be justified for simple improvement, however, lead to poor estimates and low quality implementation. To avoid this, the product owner or tech lead of the team can ask specific implementation questions to the team members and stimulate discussion by asking if others agree with that opinion. They could also themselves suggest options for the implementation strategy of a backlog item and ask the team for their preference.

The start stop continue method

Nick Scheynen 🇧🇪 — Tue, 22 Feb 2022 07:13:39 +0000

What is the start stop continue method?

Start stop continue or start stop keep, at its core, is a method used to regularly reflect on ongoing events for a certain timeframe in which performance is evaluated. This is clearly shown by the three components it uses to structure thoughts. Let's break them down:

Continue or keep is used to highlight strengths and/or things that went well in the timeframe that is being reflected on. Additionally, continue also suggests there's a future timeframe. Items that fall in the continue category are thought to also lead to success in the future.
Stop is used to indicate things that blocked or decreased performance during the past timeframe. The stop category is not meant to be a direct action item i.e. it might not be possible to simply stop doing the things filed under this category. The items in the stop category should rather be used to start a discussion for action items.
Start is used to raise new idea's or behavior that can improve performance in the future. It's important to note that items in the stop category can often also be represented by an idea to address that issue.

Now that we understand the main components of the start stop continue method, it's clear why it has become so popular in agile organizations. Agile values transparency, regular feedback and continuous improvement and start stop continue provides an easy framework to structure regular conversations around performance. Therefore, start stop continue is often used for collecting 360 degree feedback from peers, structuring 1:1 feedback to a direct report, giving bottom-up feedback to a manager and in scrum teams for the retrospective at the end of the sprint.
In the next sections, we'll dive a bit deeper into those specific use cases and provide tips and examples for using the start stop continue method effectively.

Using start stop continue for giving individual feedback

How to use start stop continue as a manager

As a manager, start stop continue provides a simple model for collecting feedback from the peers of your direct report f.e. as part of a 360 degree review. As described above, it helps peers structure feedback in a way to raise things positive (continue) and negative (stop) points and leaves room for suggestions (start) all in the context of continuous collaboration and regular feedback gathering.

Collecting feedback
The collection of this feedback can be done, by directly asking people through email or by direct message, but also by sending a simple Google Form as shown below:

In the settings tab, you can control whether to collect the responses anonymously or not. I'd suggest turning on the setting to limit the responses to 1 per recipient, but to encourage open and honest feedback not collecting the email addresses.

You can access the sample form here.

Processing peer feedback
After the employees' peers have provided you with their feedback, it's up to the manager to go through the it. As a manger, try to spot both patterns in the feedback that point to the same behavior or characteristic, as well as pieces of feedback that contradict each other. The pieces of similar feedback will help you with either something to praise your report for or provide an area where adjustment is required. For the latter, try to come up with some ahead of delivering the feedback.
Depending on whether you want to share all individual feedback items directly with your report, you can also summarize the different pieces of collected feedback.

Delivering feedback
Right before delivering feedback to your report, give them a chance to go through either your summary or the full feedback collected and ask them to reflect on it for a while. Timing is important here, the sweet spot is usually an hour or two, which is long enough for the employee to properly think things through while also not being long enough for the employee to overthink things that need context and discussion.
As a manager, I suggest to start the meeting with the employee's self-reflection on the feedback. See yourself as a coach helping them contextualize the peer feedback and, from the preparation you did yourself ahead of the meeting, make sure to openly praise the good feedback, as well as suggest action points for improvements in the next evaluation timeframe.

Examples of start stop continue feedback

Below you can find some examples of what your employee's peers could raise to you as a manager using the start stop continue method:

Continue

This developer great at onboarding our new team members. They are always available for questions and pair-programming sessions.
This product manager prepares detailed tickets ahead of the refinement.
This product manager protects the team well from stakeholders coming with distracting feature requests.

Stop

This developer tends to expand the scope of his tickets by doing unnecessary refactoring work, leading to delayed delivery of features and the team not making the goal.
This product manager often changes the scope of a ticket during implementation in a sprint. For an optimal workflow, we should rather file a separate ticket.

Start

This developer should consider speaking up more in the refinement meetings. From personal discussions, I know he has great idea's.
I would like it if the product manager provides us with a bit more business context, so the team has a better understanding of why we're building these features.
This developer should make sure they take more initiative writing up a ticket when they have a new idea.

Using start stop continue for scrum team retrospectives

Retrospectives in Agile software teams

The retrospective, a.k.a. retro, is one of the cornerstone rituals for both agile teams that use scrum as well as kanban. As explained in the introduction, the start stop continue method is useful to reflect on ongoing events at the end of a timeframe in which performance is evaluated. In scrum this timeframe intuitively maps to the length of the sprint. In kanban, it's up to team to define how often they want to check-in on their performance.
The performance of an agile team that is being reflected on in the retro can be summarized as "Did we achieve the sprint goal we set ourselves in the planning meeting?". The answer to that question will typically correlate with other, more practical, indicators of performance like: high sprint velocity or high sprint completion rate, low amount of bugs, good collaboration in the team, accurate estimations, no unexpected blockers etc.
There's many different formats for retrospectives, but they all have similar goals: look back at the past timeframe, be transparent about performance and facilitate alignment of the group for improved performance in the next timeframe. In this article, we'll dive into more detail on start stop continue retrospectives.

The start stop continue retro

The start stop continue method is one of the most popular formats for agile retrospectives. A typical retro using this format would be scheduled at the end of the sprint for 30-60min. It is attended by the full scrum team, including the product manager, all developers and testers. It is usually facilitated by a scrum master, or a (rotating) team member. The facilitator isn't meant to put forward any new idea's, but instead facilitate discussions and make sure the meeting stays within the planned timeframe. A start stop continue retro typically has the following four phases.

Brainstorming
All team members, individually, take some time to reflect on the past timeframe and write down some notes in the three different categories.

Idea sharing and grouping
After all team members have completed their notes, the facilitator pulls the team together around a board (online or offline) that has area's for the start, stop and continue categories. Next, the team members, one after another, share their notes by putting them in the categories on the board. They may also give some extra explanation to ensure every team member understands what's meant. If team members as additional questions, it's important for the facilitator to keep the discussion to clarification only. Further discussion of the idea's will come at a later stage in the meeting.
It's common that different team members come up with similar idea's while reflecting on the same sprint. For those cases, group the similar notes together, so they can be used as a group for the next phase of the retro.

Voting a.k.a. Dotmocracy
After all notes have been shared and clarified, as well as duplicates grouped, it's time for the voting round. In this round, all team members get a certain number of votes to indicate the notes they think are most important to further discuss in the team. A member can cast multiple votes on one note and, given they indicate things that went well and that the team wants to keep, the continue idea's are not the best candidates for further discussion.

Defining action points
Once all votes have been cast, the facilitator counts them and orders the notes with the descending number of votes. The rest of the retro is used for more detailed discussion and definition of action points for the team as a whole or specific members. The facilitator needs to make sure the discussion stays on track, such that the team covers not just one note. They should also make sure the action points get documented.

Examples of start stop continue retrospectives

Continue

Sharing the list of tickets before the refinement and adding questions.
Take over the ticket from team members that are out sick, in order to achieve the sprint goal.

Stop

Underestimating the tickets for Module 123
Overrunning meetings and take certain discussions offline

Start

More pair programming sessions with new-joiners
Planning documentation tickets as part of the sprint.

Action points

Product manager to share list of tickets ahead of the refinement meeting such that the team can prepare better
Everyone to raise it when a detailed discussion should be taken offline such that meetings can end in time

Introducing Scrumpal to help solve key challenges for software organizations at startups

Nick Scheynen 🇧🇪 — Mon, 14 Feb 2022 07:00:08 +0000

My background

For the past five years, I've been working as a Product Manager at fast growing startups. During that time, I got first-hand experience with the many pro's and con's of the industry. Startup employees usually get excited by chances to grow quickly, solve interesting problems, work with innovative technology and experience a big sense of ownership for the problems and solutions they work on. At the same time, they can grow frustrated or demotivated by long "flexible" working hours in teams that never are quite fully staffed, an ever-growing amount of internal politics, inexperienced managers, lack of seeing the bigger picture and an environment where efforts to grow always win from efforts to solve existing problems.

Drawing from my experience and as an engineer turned product manager who likes to work on side projects during his spare time, I'm keen to explore solutions for those challenges. As side projects need a niche and my experience as a product manager, I'm planning to focus on the particular challenges for software organizations.

Challenges for software organizations at startups

Members of a software organization

Next, I want to zoom in on what I mean exactly when I use the words "software organizations" and define who's part of it. Let's start from the place where the software gets written, the two-pizza team as coined by Amazon¹. Depending on the exact problem space or domain the team is responsible of, a software team can consists of a couple of engineers (front-end, back-end, machine learning etc.), a technical lead, software testers (manual and/or automation), a product manager and/or product owner, and potentially a designer, scrum master, analyst. A software team usually has a specific set of internal and external stakeholders (clients) it serves.

Usually the engineers in the cross-functional team report to the technical lead in the team. All other team members, including the technical lead, report to a functional lead that works across a group of multiple software teams. Depending on the organization size, they make up one or multiple layers of middle management.

At the top of the organization, there's the executive level made up of VP's, directors and C-level leaders of the company who set the overall strategy and run the company reporting to its owners.

Challenges for engineers at startups

Key challenges for engineers at startups often include:

Not understanding how work contributes to the company strategy
Big time pressure
Lack of clearly defined processes
Lots technical debt
Lack of documentation
Inexperienced management
Understaffed teams
etc.

Challenges for product managers at startups

Key challenges for product managers at startups often include:

Unstable company priorities
Different stakeholders with competing priorities
Unclear domain ownership
Big time pressure
Non tech-savvy stakeholders
Lack of documentation
Lack of clearly defined processes
Inexperienced management
Understaffed teams
etc.

Challenges for product and engineering leads at startups

Key challenges for product and engineering leads at startups often includes:

Unstable company priorities
Time pressure from executives
Getting executive priority for infrastructural vs strategic projects
Retention in their teams
Meeting hiring targets to support scaling the organization
Keeping a pulse of what's going in different teams
Coordinating on cross-team initiatives
etc.

Challenges for executives at startups

Key challenges for executives at startups often includes:

Aligning on strategic decisions amongst each other
Communicating a vision
Ensuring the organization structure aligns well with the company vision
Getting budgets approved from the board
Retention of employees
Hiring the right leaders
etc.

Introducing Scrumpal

As you can read there's no shortage of valuable problems at software organizations in fast-growing startups. I'm very keen on exploring solutions to address some of those issues. The next question is how to deliver solutions in a way that they can be easily adopted by many organizations. For that I'd like to start from the most common approach/frameworks to organize work and collaboration at startups.

As Agile SCRUM is the most common way of organizing work and collaborating in software startups, I'm kicking of this new project under the name Scrumpal. My vision for Scrumpal is for it to hook into the common SCRUM rituals to help address key challenges for software organizations at startups.

I'm looking forward to share some of my more specific idea's with you in the following posts. In the meantime, if this article resonates with you, make sure to put your email on the waitlist or reach out to me via the contact form. I'd be very keen to hear your thoughts.

References

Two-Pizza Teams - Introduction to DevOps on AWS (amazon.com)

Introducing Course Kudos: The IMDB of Online Learning

Nick Scheynen 🇧🇪 — Thu, 26 Mar 2020 10:30:45 +0000

In the fall of last year, a couple of months after I shut down my last side project, I was looking for what to build next. I had just finished a video course on how to build applications using Spring Boot and React to get a bit more background on the stack that my team (I'm work as a Product Manager) wanted to use for our newest project. I had also listened to a couple of podcasts about people building courses and learning communities, as well as seen a colleague of mine share a good video course in our company Slack channel.

Those signals and the experience of having struggled myself to, among a huge offering, decide what course to buy when I was interested in learning something new, all came together and made sparked a question in me. Why is there no central place for finding, tracking, rating good learning resources?

Of course all big learning platforms have their own rating systems, but they all differ from one-another. This makes it very hard to do cross-platform comparisons. On top of that, there's a lot of independent course creators out there, as well as a high-quality free content.

That was it, my next side-project! About 2 months later, I launched Course Kudos. After adding a couple of additional improvements, it's time to introduce it to more people and hopefully get some feedback as to where to take the project next.

What do you want to learn and how?

Course Kudos is structured around topics. They get added as tags to learning resources. Every topic has a page that lists resources to help you learn it. Learning resources have a type like book, video course, article etc. as well as a pricing type and platform. These taxonomies can be used to filter the list of resources and to also help you find how you prefer to learn.

Give kudos to your favorite teachers

If you come across some great learning content, that taught you something valuable and/or develop yourself in a meaningful way, you can help the teacher and peers by leaving a great review. Likewise, if you just spent a bunch of money on a course that didn't meet expectations, you can flag this for others as well.

Track and share what you've learned

Your profile lists all resources that you have reviewed and can be used to show your boss, future boss, client or simply yourself that you always keep learning and improving yourself in meaningful ways.

Any feedback?

The website is very much in an MVP stage at this point and I have so many idea's for new features. However, before I get to those, I want to hear your feedback. Below questions are of particular interest.

Let me know what you think on Twitter @shinyventures or via email nick@coursekudos.com.

For students:

How do you decide what to learn next?
How do you decide what course to buy?
How do you keep track of good learning content?
How do you share good content with peers?

For teachers:

How do you collect feedback from your students?
How do you find new students for your course?