fbpx

Three things to consider before agile work can be ‘ready’

Learn the purpose and value of defining the term ‘ready’ agile product management

Tip 1: Know the purpose

The purpose of collectively defining ‘ready’ is to ensure that any uncertainty is lowered significantly, making it completely reasonable to take the item into the sprint.

Once you know the purpose you can work out how your team might actually benefit from having your very own definition of ‘ready’. Each team is different and will benefit in different ways. Once it’s established, your definition of ready will act as insurance policy for team. It creates an agreed level of refinement you’re willing to commit to before starting the work.

Write down the criteria that make up your definition of ready and use it as a checklist. Hold it up to each sprint feature before you take it into the next iteration for a good chance of completing each and every item.

Tip 2: Value versus risk

In each refinement session, you’re balancing the value of the item against the risk in definition of ready. It is a delicate balancing act to spend the right amount of time understanding what’s being asked without over analysing and reducing the amount of value in the output.

With your very own definition of ready you can do exactly the amount of refinement required and no more. Be sure to factor in all potential risks when deliberating on the work. Personally, I’ve worked with a team that had very specific requirements for work sign off. It would’ve been very risky to leave the sign off until the inside of the planning iteration, so we agreed to do more work upfront to counterbalance that risk.

This is an extreme scenario to show how the definition of ready can be used. Generally the goal is to maximise the value of work not done, and keep the work before the iteration as light as possible.

Tip 3: Ready to review your ready?

You might start with an ace definition of ready at the beginning of the product life cycle or when the team is first forming. As is expected, things change and people’s expectations of your work change with it. This is a perfect opportunity to update your definition of ready.

Just because you formally agreed on it previously doesn’t mean it must stay that way forevermore. Take what you’ve learned from your previous definition and adapt it to fit these new requirements.

 

I hope these tips help you to understand and implement your own definition of ‘ready’ during your backlog refinement meetings. As a result, the consistency in readiness of sprint features and the reduction of overall risk will help you to run better end-to-end sprint iterations for your team.

If you have any questions or topics you’d like me to cover, leave a comment below or send me a message through my website. Thanks for reading. See you next time!

Here’s the full transcript:

-Hi, Georg Fasching here, helping you unlock your team’s genius. In this video, I’m focusing on the definition of ready. This is another episode in the Power of Three Series, where I’m spending just three minutes on my top three encouragements and tips on a particular subject. And with that, let us put three minutes on the clock and take a closer look at the definition of ready, starting now. Right, so in Agile product management with Scrum it is a very common practice but I don’t see it in all the teams so I thought it’s worth pointing out and including it and doing an episode on it. So, the first thing is to actually review whether you would benefit from a definition of ready, and a definition of ready is of course, a little bit of an insurance policy for the team when it comes to the fidelity or refinement level of items that you agree to take into a planning iteration or you agree to take into a sprint. So, at the least it could be a very valuable checklist to ensure that you are indeed ready to start work on a particular item. So, first thing besides actually having one that I encourage you to do is to remember its purpose, right? It’s purpose is to ensure that you only start work on things where you have lost the degree of uncertainty, to a degree where it is reasonable to take the item into the sprint, where the team hasn’t done enough preparation on it and has prepared everything that it needs to in order to have a very good chance of being able to complete the item in the next planning iteration, right? So, that is the first one. Firstly, have one, it is usually very valuable to do so and remember its purpose. The second thing that I’d like for you to do is tied to the overall backlog management is to actually balance the value versus the risk of how you’re describing your definition of ready. So, you want to ensure that you do just enough work on the particular backlogged item before you start the real work on it in a planning iteration in a sprint. And do only that amount of work that allows you to then be able to finish the work in the planning iteration. So, if you have a particular risk factors that it needs to include, so for example, I worked with a team in the past where we had a very specific requirement for sign offs. It would have been very risky for us to leave those sign offs to the inside of the planning iteration so we agreed overall that we need to do a bit more work up front in order to manage the risk. It’s generally not a ready practice that I would recommend but just as an example of where you need to balance value versus risk. And the last thing that I would like to, encourage to do when it comes to the definition of ready in your agile working is to also review it regularly. You might start off with a definition of ready at the beginning of the product life cycle when you’re getting together as a team. And then over time things change, and you might be able to do a little bit less or a little bit more, or things a little bit differently. So, just because you agree on the definition of ready at the beginning doesn’t mean it has to be exactly that way over time. Very much so you need to review it on a somewhat regular basis and with that our time is up. And these were my top three tips and encouragements when it comes to the definition of ready. Hopefully this will help you further improve your practice and your team, and also help you with your backlog refinement. And with that, all the best for your practice and your team. I look forward to hearing back from you, sharing your thoughts that you have and ideas from you. Drop it in the comments below and please like, share, and subscribe this. And until the next video, all the best, thank you, bye bye.

Photo of Georg Fasching

From the desk of Georg Fasching, passionate purveyor of Product Flow, and seasoned executive, team, and organisational change coach.

For his high-leverage, curation of methods and instruction, visit https://get.teamgenius.eu/.

Please share your thoughts and queries on the content above in the comments below!

3 thoughts on “Three things to consider before agile work can be ‘ready’”

Leave a Reply to How to have a healthy Product Backlog - Unlock Your Team's Genius Cancel reply