Today I read an article on various approaches for Product Backlog Grooming meetings. Underlying the write-up there seemed to be some misconceptions about the purpose and goals, the duration, the participants, the approach, and how often and when to hold a Product Backlog Grooming meeting.

Purpose and goals

The Agile Atlas Core Scrum part mentions the Product Backlog Refinement activity. It’s not necessarily a meeting, but up to 10% of the Development Team’s Sprint time might be used on refining the backlog.

The main purpose of refining the backlog lies in rebuilding the product backlog so that adheres to the DEEP criteria: detailed appropriately, estimated, emergent, and properly ordered (originally: prioritized, but I threw in a deliberate renaming based on recent changes in the Scrum guide).

Detailed appropriately means that we have some product backlog items very detailed. These should be at the top of the current ordering, and they surely will be implemented during the next one or two sprints by the team. On the other hand we have some vague ideas about the product in the future. Some folks call these epics, like large user stories, some call the themes. What really matters is that these are too large, too undetailed to fit into one of the next sprints. We surely have to work on them, refine them, before the team will be able to forecast them in a sprint.

In between there is a large variety of details in the product backlog items. Some are very high-level, others are close to being appropriately for the next sprint.

As part of the backlog refinement activity we have to work with the product backlog to be able to fill at least the next sprint with it. That usually means that we would like to detail enough stories for the next three sprints at most. Detailing more would mean to invest much more effort into unsure work in the future – that could be waste, especially when priorities change based on feedback from the market and customers. Preparing fewer items than for the next sprint accompanies the risk that the team at the next sprint planning will be able merely to plan two stories, where five would fit in. Most teams I have seen do well with having a constant pipeline of one to two sprints worth of backlog items “sprintable” in their backlog.

The backlog also should be estimated. That means we need to do estimation on those items we worked on. These two things together, detailing items, and estimating them, is usually what teams do when they speak about the Backlog Grooming meeting. The emergent and ordering parts – not so much.

That said, the main purpose for the Backlog Grooming meeting lies in preparing enough Product Backlog Items for the next Sprint. Depending on your Product Owner’s rendevouz demand with other folks, you may also need to work on some larger stories, estimate them, and prepare them so that the scope for the current release can be communicated.

Duration and frequency

Time-boxing is a way to foster hard-to-make, critical decisions. In Scrum all meetings are time-boxed. That should also yield for the Backlog Grooming meeting.

Given the Development Team can help the Product Owner on the Product Backlog Refinement up to 10% of their time, that means we could schedule a one day long Backlog Grooming meeting with the whole team on a two week sprint length. I wouldn’t do that. It not only would mean that the team cannot work with the Product Backlog during the rest of the sprint. It would also mean that the team is pulled out of their current sprint for a full day.

What I have seen working for most teams is a weekly one hour Backlog Grooming meeting. When the Sprint starts on a Wednesday, for example, I would schedule the grooming meeting for Mondays. As a Coach or ScrumMaster I would also help the Product Owner to prepare the stories for the grooming meeting, and if there is not sufficient input for a full grooming meeting, I would either cancel the meeting, or make it shorter.

The frequency with some offset to the review, retrospective, and planning meetings helps to make sure you can still clarify open questions for the highest priority items before the planning meeting. Otherwise you would have to leave out an unclear item from the current sprint, even though it has the highest priority right now. That’s usually not a desire.

With one hour each week you also help the Development to focus on their current work most of the time. Your mileage might vary, indeed, but I would be worried if you have to use more than two hours every week on grooming your Product Backlog. That either means that the knowledge gap between the business side and your Development Team is too large, or you have too many uncertainties in your current backlog. Oh, of course, it might also mean that you are deeply into team building, and people try to distract with their hidden agendas during this meeting. Regarding the knowledge gap, you should try training some of the team members in the business domain, either on-the-job with end users and domain experts, or merely send them on a course. Regarding the uncertainties, that might mean that you need to bring a subject matter expert on your team to help them, or you need to invest more effort before being able to have an item in a sprint. These issues usually shouldn’t be solved with more grooming, a longer meeting, etc. The grooming demand instead makes you aware of a potential problem that you should tackle differently.

Participants

At least you need someone with a business domain background, one with knowledge about technical limitations, and one who can challenge the thoughts in the room for completeness, or validity. At least this includes the role of the Product Owner, a programer, and a tester. Some teams do well with just these three experts on their team. Other teams find it more useful to include everyone available in it. I usually start with the latter approach, and lower down the number participants when necessary.

Approach

With the purpose mentioned above, the Product Owner takes the first product backlog item that needs to be either estimated or become more detailed, and the team explores ways to do that. Ellen Gottesdiener and Mary Gorman’s Discover to Deliver provide some more details on this. For the estimation part things like planning poker, bucket estimation, or blink estimation come to mind.

For the detailing part, usually that means to break down backlog items by using one of the splitting cheat sheets available, or exploring ways to break a larger item down into several smaller ones by simply talking. Nonetheless you should be aware of strategies like Dimensional Planning for this as well…

The key thing here is that you should not talk through the whole Product Backlog in one hour every week. That will be dragging for everyone involved. Instead, focus on the most immediate priority. That usually is to be able to fill a sprint from the current Product Backlog. With the time-boxing to one or two hours, you might end up being partly through the backlog, and that’s absolutely ok. In the next week you will be getting deeper into with the next stuff. viagra

On the bottom of James Bach’s recommendations of people there is a small paragraph:

That One German Guy

Germany has no excuse. There are TONS of smart people there. How is it only one intellectual software tester has emerged from the ISTQB-addled masses to demand my respect with his work? My theory is that Germany has a more command-and-control culture, which perhaps disparages independent thought of the kind required to achieve excellence in testing. This pains me, because I am descended from Germans and I would love to visit and teach there.

Anyway, the one German guy who shines in my community is Markus Gaertner. I’ll do a write-up on him, shortly.

Yeah, it’s about me. From time to time I am asked by James and other people in our community where the German testers actually are. Here are some folks I am in touch with, that have raised my attention, and I think will need some attention from the wider community. There is not only one guy testing in Germany, seriously.

Meike Mertsch

Meike Mertsch is not only my colleague, but upon joining James’ tutorial at the Swiss Testing Day last year, James got in contact with me over skype along with these lines:

I have met Meike. Now I know two testers in Germany.

Meike is more a developer-tester, but I think she has some potential. I work with her partially as a colleague, partially as a mentor.

Alexander Simic

For quite some time I have been in touch with Alexander. He is working with James as a testing coach, and besides Meike and myself was the third participants at last year’s GATE peer workshop. Alexander is working in Freiburg, eager to meet other like-minded folks.

Maik Nogens

Maik and I started this thing called GATE a while ago. Last year, he couldn’t make the date, though. That does not mean that we are not in touch with each other. In fact, he’s right now co-organizing the Software Testing user group in Hamburg.

Tobias Geyer

Oh, yeah, Tobias is the guy that made me aware of the Software Testing user group in Hamburg at the Agile Testing Days 2010. Since then some things have changed, but I think highly about Tobias, and I think he started a great community in Hamburg there. It’s a bit of a pity that Hamburg seems to be the only user community in Germany I am aware of.

Ursula Beiersdorf

Ursula Beiersdorf right now co-organizes local testing events in Hamburg, Germany together with Maik. I think she is doing a great job in networking and getting testers together.

Stephan Kämper

In 2009 I sat in the same tutorial at a conference as Stephan Kämper. Over the years, I came to value our exchanges on testing, and the greater community.

Andreas Simon

Andreas Simon is the guy that went to the very first Belgium Testing Days on his own budget to attend the Testing Dojos that I facilitated there. We had quite some fun together. Over the past two years, we came to co-organize the local Software Craftsmanship user group in Münster-Osnabrück-Bielefeld, he also organizes Coding Dojos and Code’n'Cake meet-ups in Münster as well.

More

I think there are more. For example there was this guy, Ender Ekinci, who dived deeply into the problems with Parkcalc, and found a way to produce even higher parking costs.

There also is Moritz Schoenberg who I don’t know in person (yet). I became aware of him since he won the uTest award for the tester of the year in a row. I hope to get in touch with him at the next official GATE workshop.

Oh, and of course there is Christian Baumann who attended the first GATE workshop in Hamburg in 2011. He’s been on my radar before that. That usually means I had the impression he is worthwhile to follow.

A final disclaimer: I think I might have forgotten some more people I work with in user groups, and other communities. If you miss your name on this list, drop me a line, and I will check whether to do a follow-up with your name included as well.

Last, but not least, this should be a starting point for you, German testers, to get in touch with us. I think we can excel beyond the state of our craft that we are currently working in. But we need to network better for this to happen.

Here is a thing I learned from J.B. Rainsberger at XP 2012 in May 2012. I used it in the past months quite extensively for debugging communication based upon the Satir Communication model. While doing some research for this blog entry, I discovered that some others have also written about the topic. I especially liked Dale Emery’s Untangling Communication which seems to go a bit deeper than my understanding of the topic. Anyways, here’s my write-up which might give a different perspective.

The Satir Communication model

Family therapist Virginia Satir developed model about communication. Jerry Weinberg wrote quite extensively about it in several books. However, the first time I really understood the model, was in the context of debugging communications.

Let’s dive into the model, first. There are four phases when a a human receives any form of communication: intake, meaning, significance, and response. Let’s dive deeper into them.

Intake

During information intake we humans take in the message the other person communicating with us is trying to give us. We take in the words the other person says, we take in the body language, we also subconsciously notice things the person is sending to us. For a web blog this mostly consists of reading what is there.

Needless to say that the amount of communication we may intake depends largely on the communication channel used. For face-to-face communication the amount of information that I can notice is much wider than for example for text chat exchanges on the internet, or asynchronous written communication like email or twitter.

We’ll take a discrete look on the things that may go wrong in a few.

Meaning

After taking in the message as it was said we start to interpret the message based on our previous experiences with the person we are interacting with. That might mean that we come up with the worst possible interpretation, for example when we deal with an identified patient, that is someone we mostly see as the troublemaker. That might also mean that we come up with the most positive interpretation for a person that we love or feel close to.

We form interpretations based on our previous experiences with the sender, or based on our skills on intake. We combine the intake of the message together with our previous knowledge of the situation, the environment, and our previous experience in similar situations like this.

Significance

Taking our intake and our interpretations into account, we form significance to the message. Significance is based upon upon our feelings about the situation, how we experienced similar situations in the past, and the good or bad interpretations that we came up with. But also the surroundings of our family life might lead to different significance assignments for the message we received.

Response

Last, but not least, we decide whether or not to respond, and what an appropriate response will look like. We base our responses based on the information we took in, the meaning we formed from it, and the significance to the message that we attached to it. For example, in a particularly stressed situation in your family, you will respond differently as when everything is alright at home.

When things go wrong

But what happens when things go wrong? And how does the model help there? In order to debug communications, I go through the phases in order to check where something went wrong and to correct the situation from there. So, let’s go through the phases to see where communication might go awry, and what we might be able to do to resolve the problem early.

Intake

When something goes wrong during intake, we understand different things. For example when I write the word “integration test”, there are at least two different meanings I am aware – that’s why I usually try to avoid that term. Other such terms are for example to my experience “quality”, “testing”, and “agile”.

When something goes wrong during information intake, we end up with a misunderstanding. That means that the sender of the message had a different understanding of the term than the receiver, and we end up with something called ‘shallow agreement’ if we don’t find out about our misunderstanding before agreeing together on something.

In order to check for misunderstanding in our communication I try to ask clarifying questions. For examples when I am asked to create better quality, I ask for more specific details about the term “quality”. When someone asks me for “best practices”, I ask for a definition of that. I think that is also the reason why we allow clarifying questions in LAWST-style peer conferences.

Meaning

Weinberg’s famous Rule of Three Interpretation origins from this phase. To cite Quality Software Management Volume 2 – First-order measurements on page 90:

If I can’t think of at least three different interpretations of what I received, I haven’t thought enough about what it might mean.

That means that at times I might end up with a different interpretation than the sender has. If we are not on the same page regarding our understanding of the words, it is also clear that it’s more probably that we end up with different interpretations regarding the situation.

When dealing with misinterpretations, that is we attach different interpretations to the communication than the sender tried to send to us, we need to explore the situation a bit deeper. How come the sender came to the interpretation? What other intake of the situation did he come up with? Most of the time I find out there are other contributing factors that I was not aware of so far. By asking the Data Question I at times explore the interpretation:

What did you see or hear (or feel) that led you that conclusion?

(Gerald M. Weinberg, More Secrets of Consulting, Dorset House, page 114)

Significance

In regards to significance, I need to go a bit deeper. I need to explore feelings of the sender. For me to understand the significance the sender attaches to a particular situation or communication, I need to ask for previous experiences. I don’t have that many experiences with dealing with those situations. Most of the time this highly touches our inner beliefs. To be honest, I have not found many ways to change those other by providing different experiences.

I haven’t been in too many situations where communication went wrong in the response part. That’s why I don’t dive deeper into it here.

Last, but not least, I usually find myself already in better communication with the first two parts, as most of our communication seems to go awry there. viagra

Recently I restarted the Wandering Book. The Wandering Book is a tiny book passed on from Craftsman to Craftsman, fromCmmunity to Community intended to collect the Zeitgeist of Software Craftsmanship. I deliberately decided to start passing this to the German Softwerkskammer user grups. The idea is to collect the different notions, sort of a guest book of all the local events happening all over Germany.

Since the first book seems lost, I decided to put a disclaimer in it at the beginning. Here is the initial entry I made.

More than four years ago, Enrique Comba-Riepenhausen stated something called The Wandering Book. It was a tiny book like this one and a website where you could sign up for it. Once I realised what it was, I signed up immediately. Since I need longer sometimes, I was at position 54 or something in Enrique’s list. Then in late 2010 I received the book finally.

I made my entry in it, shared pictures of it on my blog and forwarded it to the next adress as instructed.

I never saw The Wandering Book again.

Neither physically, nor virtually. Things changed, so now the web archive of the original book is ever gone. All Zeitgeist from these early days of the Software Craftsmanship movement – seems – lost.

A few weeks ago I decided to restart this. Thus I called out for the German communities, and we decided to pass this around in the local events.

So if you find this precious book and you don’t know what to do with it, it’s probably lost – again.

Please find the next local Software Craftsmanship community and pass this on to them. The History of Software Development will thank you.

Andrii Dzynia sent me this report from the third Ukrainian Testing Dojo. This is the English language report for this Russian original. I still think they are doing awesome stuff over there in the Ucraine.

Testing Dojo Ukraine #3 has taken place last week.

Some of the participants were there third time already. Means they like it and want more

The goal of the event was to test Android application – CxRate. One of the founders of the application Alex Filatov visited us to present this app and help guys with questions and potential issues.

We spent first session for touring over the app to understand it’s purpose and features. All the participants were working in small groups that helped then to collaborate better.

When 25 minutes passed we started our first Debrief. Using PROOF mnemonic (Past, Results, Obstacles, Outlooks, Feelings) each team gave short feedback about stuff they did and which areas left to be tested.

One of the team prepared Functional Map that we shared on the screen for all audience.

Seconds session was much more intensive. Next 25 minutes testers was strongly focused on bug-hunting process to find as much bugs as possible. Alex(app developer) helped a lot with all the questions that occurred from the guys.

After next 25 minutes and one more Debrief I’ve made small presentation to the testers/reporters about mnemonic for mobile testing called “I sliced up fun” by John Kohl. It gave more ideas that can be tested in the app.

Third session was the latest and was focused mostly on preparing useful and readable report. Each team sent their report to the developer with the bugs list and suggestions. Alex said they have to postpone the release for two week to fix all those issues. But the product definitely will be higher quality it was before!

At the end we did small feedback session to talk about Testing Dojo in general. Participants gave many interesting suggestions and ideas how it can be improved.

Stay tuned with Testing Dojo Ukraine!