# Things I've learned refining work items in software projects

*"I'm responsible about what I write, not about what you understand."* - **No!!!** Everyone is responsable about the effectiveness of the communication. And that's it what about refining is: alignment, clear and objective communication!

Frequentily while talking with friends or customers that are about to adopt agile methodologies I realize that are a lot of doubts about refining of work items (or grooming, but it was discontinued and removed from the [Scrum Guide]( "http://www.scrumguides.org/scrum-guide.html?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3B973ymQSnT12L8S%2BZYU0F%2Bw%3D%3D") since 2013).

There are also doubts about the importance of the process: *"Why I have to use it on my team?"*, *"Is that really useful?"*. I belive that the refining process is extremely important to a good and healthy project or process. The main goal is to make work items better described with less uncertain. It's execution aims to create a better alignment of the expectations of all interested parts, so everyone could see what will be constructed. There are a lot of benefits, like:

- With better described work items the conclusion forecast it's clearer;
- The chance of an unforeseen event appear during the development process that will become a block will be smaller;
- Everyone in the development team will be aware of all the steps to finish the work item.

The cloudy point for a lot of people is the writing and the understanding of the work item. A good understanding about the subject, and what I believe, is:

- If the understanding occur during the same moment, the planning, the replenishment, refining or any other name you may use. And you begin to write the work item, adding doubts, acceptance criterias and everything else at this moment. I believe that your **refining is a meeting** (although all meetings are - or at least should be - a process);
- If your understanding about the work item comes before the meeting, a few days earlier you start to look for the impediments, doubts, acceptance criterias, dependencies, integrations and everything else so the work item will be close to ready to dev at the moment of the meeting. I mean, you're doing a **process** of understanding of the work item, so your **refining will became a process**.

And why I'm explaining it? 'Cause my intent with this post is to defend and show the advantages to treat the refining process as a process and not as a meeting. But before we start, what is a process? One of the possible meaning is: *["a continuous action, operation, or series of changes taking place in a definite manner"](http://www.dictionary.com/browse/process)*. In that case, **the goal of a refinement process is to generate work items ready to be developed**.

OK, so what's the reason to transform the refining into a process, and not a meeting?

I believe that are some reasons why the process is better than the meeting, and it creates better described work items as an output. Those reasons disturb less the development team, they occupy more time at the process manager, although flexibilize for all the others. It's very good, right? But how?

When you define a refinement process, making clearly all the steps before and after the meeting, you will achieve some crucial points:

- You will be better prepared to the meeting: knowing that you will facilitate a meeting you will make a prep (at least, I hope so), right? So, when you define the process correctly, you know all the steps you will take to be prepared to the refining. A good meeting is influenced by those factors: a well definied schedule, it has to be time-boxed, you only call the people that really need to be there, and last but not least a facilitator to make the meeting fluid;
- Optimize the team time: when you get prepared to a refining, writing the work items before, making researches and making notes of the possible doubts you are reducing the time that everyone will need to be together doing it. Optimizing the time of all the involved;
- Reduce the possibility of daydreams: how many times you were talking about a work item, and suddenly someone starts to daydream during the meeting? Talking about things that are not related to the main goal of the item. Bringing work items better described to the meeting at the moment of the discussions it will reduce the chances of someone starts a deliberation of something that is not at the work item objective.

### Nice! And how to do a refining?

A very important thing is to define the process. I usually say that I divided the refining process in two parts. The pre-refining and the refining meeting (or, just refining to be easier). The first part is to understand what will be done, the second one is the meeting with the team so everyone could have the same understanding about the work item.

#### Pre-refining

Firstly, as the responsible of the process and helping the product person I usually study the business scope so I can understand the goal of the work item, thus to have the minimum knowledge to describe and question acceptance criterias, or implementation ways (talking about business, not code). The acceptance criterias are added to the work item, to make it clear to all the involved what is needed to the item be completed, I mean, the work item be considered done.

Making this way, it's already possible to note down doubts of the product inside the work item. And that's the second step, talk with the product manager or owner. Passing the card through the first strainer and noting down doubts that could appear related to the project scope or the work item. Those questions are noted on the item, in a way that the team could see.

Then, talk with one of the developers about the work item. Show him or her what you have noted down, this is the second strainer. With that conversation with the developer some technical doubts appears, integration doubts for example.

The main idea of that step is to bring the work item minimum written to the discussion, so everyone's time is optimized. You already talked with the business specialist and with one of the technical specialists, in theory the work items now have enough information.

#### OK! I already wrote all the doubts, acceptance criterias and everything else! May the developer start the development?

Ops! Calm down young padawan, it's not that way! You validate the hypothesis of the work item with only two people. I guess your team probably has more people than that. Now we're ready to the refining meeting!

At this moment we have to get the team agreement, that everything that was wrote makes sense and is deliverable. The moment that the product manager gives his word saying "Yeah! That's it what I want as an output for the work item.". That's the moment when the quality analyst and the developers agrees how the work item will be developed and tested.

#### How to do a refinining?

First of all: bring the right people to the right meeting. As we're talking about development it's very important that some devs are in the room. We'll talk about how it will be tested, so a quality assurance person is desirable. We'll also discuss business evolution, so the product manager or product owner must be there. However, there's no need that all developers participate at the same refining meeting. The work item must be written in a way clear enough that anyone that's not in the meeting could understand and develop what must be done. We have a rule in the team I'm working now: our maximum developer participation is 50% of our developers. See, it's the maximum capacity, we could do the meeting with less.

This moment must be synchronous, no email nor wiki. Everyone in the same room, whether face to face or remote. Making this way we rise our chances to align everything faster, and to leave no doubts behind. Talking synchronously people use to understand better and participate more on the discussions.

Another two crucial points that must walk side by side: goal and time box! Before the work item discussion, set clearly what's the main goal of the meeting and how much time do you have to do so. Something like: "Folks, we have 3 work items that must be refined. We have twenty minutes to each one!". Thus, the team knows that they will have to optimize the time so the discussion must create outputs inside this time box. Another nice thing to do is, put a clock in a display, with the discussion time box. Just do a ["20 minutes timer"](https://www.google.com.br/search?q=google+20+minutes+timer&oq=google+20+minutes+timer&lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3BwclIyEZMRASoUky7rC%2Fhcw%3D%3D) in the google search and it will count for you. This way, as the team becomes more mature, they will always take care of the discussions' time box.

Remember, this is the team understanding moment. When everyone must be committed with what will be and how it will be delivered. The output must be a good written work item, so they could be pulled to the development cycle. I believe that in the end of the 20 minutes (for example), if the team is not sure about the deliverable or if that's a lot of doubts that won't be answered in 10 more minutes the work item must be pre-refined again (but now you have more information). You don't want an uncertain work item in your development flow, do you?

And how about you? How do you understand the work item scope? How do you describe what must be developed? A meeting? An event? A process? Tell me how! I'd love to know how.