Delivering Value Using Scrum

Podcast Ep. 133: Delivering Value Using Scrum with Andrea Floyd

Delivering Value Using Scrum
Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

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).

In their conversation today, they discuss delivering value using Scrum — 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’re delivering.

Listen on Apple Podcasts

Key Takeaways

  • Why is delivering value using Scrum important?
    • People want to know why they’re doing what they’re doing (and understanding how they are delivering value using Scrum answers that question)
    • Understanding what value you’re bringing ensures that you’re working on the right thing/s at the right time
    • In order to make certain business decisions, it is key to measure: “Are we getting the outcomes that we’re seeking?” and, “Are we actually making a difference in the eyes of our customers or users?” Do they see and feel what we’re 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’re doing:
    • Answer the question: “Have we moved the needle in anybody’s world? How so?”
    • Organizations should be embracing transparency and trust so there is more access to communication (and so people know the context they’re 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 — it is critical
    • You should be able to explain to your team why you are working on something (if you can’t, 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 “ready” 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’s eligible for consideration to begin working on
    • Ask: “What does ready look like for a feature?” and “What information needs to be present?”
    • Collect data and measure: “Are we getting value out the door?” and “Are we getting value into the hands of our customers or users?”
    • 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 — that means you’re 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’re 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’re done with a feature:
    • Use the definition of “done” at a release level (this is where you can articulate what features are eligible for release based on the release definition of done)

Mentioned in this Episode:

Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]

Stay Up-To-Date