Refinement Methods

What criteria do the team use to determine if work is sufficiently refined and "ready" for Sprint Planning?

As a scrum master I want to improve our refinement and usery story estimations

What is the team missing or lacking? What would like to add to improve?

Our team refinement is just about speaking and writing some requirements. neverthless we sometimes miss some parts and we have realised we have to add extra development work.

This sounds like the perfect situation to me. I would be praising the team for success instead of seeing it as a problem.

As a scrum master I want to improve our refinement and usery story estimations(including requirements,efforts etc)

As a Development Team member do I see that a problem exists?  I applaud your dedication but remember that agile in general is based upon making decisions given the current information and adapting as new information surfaces.  If you attempt to uncover all information before doing the work, you run the risk of never doing any work. Paralysis by analysis is a very real thing.  

Talk to the entire Scrum Team and ask if they feel there is a problem. If they do then start the conversation on how they feel it can be improved.  No two teams are the same so we can give you examples of what we have encountered but in the end it will be up to the Scrum Team to decide what is best for them.

Hi All

@Daniel Wilhite actually the entire scrum team seems this is a problem. But they have no idea for solving this problem. So as a SM I want to improve our refinement method @xander ladage . Actually team is missing the definition of "ready" @Ian Mitchell. That is the situation we have to solve, we must know when we are "ready".

That is the situation we have to solve, we must know when we are "ready".

Are you familiar with the INVEST criteria which are commonly applied to user stories?

https://www.scrum.org/resources/blog/walking-through-definition-ready

+1 on what Ian Mitchell said. INVEST ensures your items are "ready". 

As for PB refinement in general...



Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done.”



Some people make the mistake of seeing the session with Development Team as the PB refinement, but there's a lot more happening behind the screens. Refinement is something the Product Owner does on a daily basis.

Generally the items start with having a small user story description. “As a...i want...so that”

Before adding detail to that item, it needs to get ordered by the Product Owner on the Product Backlog, as only the high ordered items should be more detailed so as not to waste time on items with low value, can change over time and might not ever make it into the product.



For order, you need Value. I would recommend starting vague (T-shirt size S, M, L, XL) first. This tells you that the item is either High Value (XL), so you put effort in ordering it. Otherwise, low value (S) can get a rough ordering in the list. Then you can compare to other items and jump every few items till you get a good idea of where it fits relative to the other PB items.



Now you have your high value items. To add to the description the PO can ask the Stakeholders questions. What is it, why is it required, what is it solving? This makes them think about it, which helps them understand if it's really of high value and also gives the Dev Team a good starting point to understand the requirement better. 



Here the Dev Team can estimate using Planning Poker or other estimating techniques. During PP a lot of questions come out, which helps with adding detail and acceptance criteria (different to "Done" as it's specific to the item) and Test Case Requirements. If items are too big or too vague to be able to estimate, you can do what is called slicing, which breaks them into smaller, independent items. 



The HOW part is left for Sprint Planning. 



Would be keen to hear how other's go about the whole process. Hope this helps a bit.

I still stand by my original statement that this sounds great!  But I can understand the frustration at this point.  Here is something that I used once to help a team stuck in a similar situation come to terms with their predicament.  After presenting these concepts to them, they started to understand that their situation wasn't all that bad.

If you look up the definition of refinement in Merriam-Webster's dictionary it say the act of refining.  So, look up refining.  I will use one transitive and one intransitive definition.

to improve or perfect by pruning or polishing

to make improvement by introducing subtleties or distinctions

Refinement of anything is not done quickly. The process usually takes multiple iterations with each one providing more improvements than the last based on what information was uncovered in the previous attempt.  It is extremely rare to reach a point in which the material being refined is 100% pure. But in all situations, there comes a time at which the product is deemed "good enough" for the purposes intended and is released to consumers. Based on the feedback from users and continued tester by the refiners additional changes will be made to the product. Put that into Scrum terms yields that at some point the Product Backlog items at some point become "ready" enough to be pulled into a Sprint Backlog. As new information is uncovered while work is commencing or as stakeholders provide feedback additional changes are introduced.  If you attempt to achieve 100% purity on the Product Backlog item no work will ever be done. 

Just as Product Backlog Items need to be refined, so does the way that a team works. This is so important that Scrum dedicates an event for this sole purpose, Sprint Retrospective.  As the team undertakes the act of refinement they learn things about how they do it.  During Sprint Retrospective that newly encountered information should be used to refine the way that they refine Product Backlog Items. "Why do we always forget to account for the changes needed to the sitemap when we introduce new features?"  "We constantly under estimate the work needed to add items to the drop down lists in our UI. What can we do to improve that?" That last question could result in a change to the technology used for the UI or it could result in the realization that they need to adjust their views of the complexity of the work and provide more granular details in their refinements. There are many ways to improve refinements and sometimes it is by improving the technology on which the problem space exists.

And one more thing.  The act of refinement does not have to occur when all participants are gathered in a room around a table.  One of my teams improved their refinement by agreeing that every team member would spend 1 hour 3 times a week at their desk reviewing items in the Product Backlog and making notes in the item.  This allowed for some discussion ahead of everyone being in a room together.  They actually found that some items could be refined well with this technique and didn't need to be discussed in a room. 

Have the team be very critical about the way they refine and think beyond sitting in a room together.  But also make sure they understand that trying to account for everything ahead of time will most likely lead to nothing ever being worked on. The reason that agile came to be is because project plans based on estimates given before work started almost always were wrong due to the fact that information is always learned while doing the work. 

Hi Ezgi,

Lot's of good insights posted here so I won't be repeating any of them. Just want to add my 2 cents.

1) A refinement game:

If you'd like a game to guide the approach in a more process-like fashion, I suggest a Confidence Score game:

For each Product Backlog Item:

1. Check the description and specs with the team (let everyone read it through).
2. Ask the Development Team to give their Confidence Score from 1 to 5 (votes shown at the same time, like planning poker). Meaning of votes 1-5:
   • 1 = I have no clue what that is about (also known as "WTF?").
   • 2 = This item is missing essential information to allow its start.
   • 3 = I don't feel confident to start working on this yet.
   • 4 = I am confident enough to start working on this now, even though questions might arise later.
   • 5 = I am confident to explain to anyone else what is expected as the final result.
3. Compute the average score.
   • If the average is below 2, consider allowing the PO to ask the team what sort of things are missing and just skip the item, so the PO can do his/her homework. Items that are so much unclear will waste the team's time.
4. React to votes
   • For people that voted "1", there is not much for them at this point, just let them be there and listen.
   • For people that voted "2", ask what is missing.
   • For "3", ask what are they afraid of or what would make them confident.
   • For "4", ask what kind of questions or challenges they think there might be after starting.
   • For "5", challenge them to help to answer the questions of 2s, 3s and 4s, having the PO validating what they say.
5. As people discuss the score they gave, use this moment to add details to the PBI as more is revealed by the PO and the ones that voted "5".
6. Until you reach an average score of 4.5, do more rounds.
   • The evolution of the average score between the rounds can be a useful metric to identify what domains the Scrum Team find easier/harder to refine.

2) Communicating the purpose of the refinement:

In regards to helping the team understand what is the true purpose of refinement, I like to compare it to getting ready for cooking: before starting to actually cook, I like to have the recipe visible (in my phone or computer), ingredients chopped and measured, pots and tools ready, so when I start cooking I ensure to do it efficiently (I don't mean fast, but with a good balance of time spent and result achieved). I could instead start by putting the pot on the fire first, then figure out the rest, but this way my cooking process would be more chaotic, the result not as good and the kitchen would end up messier.

I hope it helps!