BROADCASTS.com

b'

This week, Dan is joined by fellow AgileThought colleague and return guest, Andrea Floyd! Andrea is an enterprise agile transformation consultant at AgileThought with over 25 years of experience in software development and management. She is an innovator who has led multiple organization-wide scaled agile implementations, and she has also architected innovative solution strategies and roadmaps across many frameworks (including Scrum, Kanban, and the Scaled Agile Framework).

\\xa0

In their conversation today, they discuss delivering value using Scrum \\u2014 what it looks like, why it is important to focus on, how to introduce the concept of value delivery in the product life cycle, and how to begin measuring the value of what you\\u2019re delivering.

\\xa0

Key Takeaways

Why is delivering value using Scrum important?

People want to know why they\\u2019re doing what they\\u2019re doing (and understanding how they are delivering value using Scrum answers that question)

Understanding what value you\\u2019re bringing ensures that you\\u2019re working on the right thing/s at the right time

In order to make certain business decisions, it is key to measure: \\u201cAre we getting the outcomes that we\\u2019re seeking?\\u201d and, \\u201cAre we actually making a difference in the eyes of our customers or users?\\u201d Do they see and feel what we\\u2019re providing and delivering in terms of capabilities is valuable?

How and when to introduce the concept of value delivery in a product life cycle:

There are a few entry points to consider

At the organizational leadership level, they need to be outlining what they feel is valuable to the organization

If leadership outlines what is valuable to the organization, everybody is able to check in with that

Someone at the top of the organization should be setting the alignment (and allowing it to cascade down through the organization)

At a product or a project level, you should start thinking about delivering value by encapsulating it in features (and having those features be on your product roadmap [which will then inform and drive your product backlog])

At a product or team level, apply your focus to talk about value at the feature level (think about the mechanisms to timebox features)

Tips, tools, and techniques to measure the value of what you\\u2019re doing:

Answer the question: \\u201cHave we moved the needle in anybody\\u2019s world? How so?\\u201d

Organizations should be embracing transparency and trust so there is more access to communication (and so people know the context they\\u2019re operating in)

Consider looking at how you do your portfolio management and have that work be hand-in-hand with investment decisions (which then will influence how you organize around the work or the product)

Leverage techniques in work management tools (such as Jira, Azure DevOps, etc.) where you can put effort at a feature level (just like you would do at a story level)

Use some form of relative sizing to forecast based on what you know today

If you are able to do feature points, map the features on the product roadmap

Leverage product goals to help your team ensure that the emergence of their product backlog aligns with the product goal

Use product goals to help you focus on the right items (in the right sequence) in your backlog, and refine those features so that your team can communicate to stakeholders and leaders how they are doing as they move forward

Leverage timeboxing \\u2014 it is critical

You should be able to explain to your team why you are working on something (if you can\\u2019t, push it down on your backlog until you can)

How do we know when a feature is ready to be consumed by a team?

It is important to have a definition of \\u201cready\\u201d so that the team is on the same page

Ideally, you have fields that indicate the state of readiness a feature needs to be at before it\\u2019s eligible for consideration to begin working on

Ask: \\u201cWhat does ready look like for a feature?\\u201d and \\u201cWhat information needs to be present?\\u201d

Collect data and measure: \\u201cAre we getting value out the door?\\u201d and \\u201cAre we getting value into the hands of our customers or users?\\u201d

There should be a level of accountability on the people that are responsible for refining the backlog (if you want to make the cut, make sure that everything is clear)

Tips regarding features and value delivery:

Business decisions have to be made \\u2014 that means you\\u2019re going to have to get comfortable with forecasting (and forecasting gets easier with the more data points you can reference)

Having an understanding of velocity is important because it is helpful in forecasting and understanding if you\\u2019re biting off more than you can chew

Andrea recommends having your product roadmap at a feature level and having a strong partnership between the product ownership and the team to help forecasting at a feature level

Andrea recommends having the roadmap be based quarter-by-quarter, one year out

How to know when you\\u2019re done with a feature:

Use the definition of \\u201cdone\\u201d at a release level (this is where you can articulate what features are eligible for release based on the release definition of done)

\\xa0

Mentioned in this Episode:

Agile Coaches\\u2019 Corner Ep. 132: \\u201cWaterfall to Scrum: How to Measure the Value of Agility with Sam Falco\\u201d

Jira

Azure DevOps

The Scrum Guide

Azure Coaches\\u2019 Corner Ep. 118: \\u201cBig Room Planning 101 with Andrea Floyd\\u201d

Agile Coaches\\u2019 Corner Ep. 29: \\u201cHow to Combat Cognitive Biases for Effective Agile Teams\\u201d

\\xa0

Want to Learn More or Get in Touch?

Visit the website and catch up with all the episodes on AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!