Matt Badgley

My career journey has had me wearing many hats ranging from Systems Analyst to Programmer to IT Manager to Programmer to Director. Today, I work as a coach and instructor to the leadership and team members of organizations on their agility journey. I'm constantly practicing to be a good learner, aspiring to be an inspiring leader, and I'm constantly walking the line between pragmatism and conviction when it comes to the application of lean and agile principles and practices.

Matt’s purpose is simple, “I believe in working with teams to help them get better, learn, and be successful in building stuff while having fun.”

At the end of the day, Matt believes in integrity, hard work, curiosity, people, and faith.

Using a Hero’s Journey to Create an Inspiring Vision


About a year ago, I was at the St. Louis airport waiting out a summer weather flight delay. As one might do in these scenarios, I went on a quest to find some easy reading that peaked my interests. I stumbled upon a relatively new book called Building a Story Brand by Donald Miller. I picked up the book because I’m always looking to be a better storyteller and, by the looks of it, it seemed like an easy read (I’m a slow reader).

As it turns out, the book was a pretty easy read, and I was able to extract some better ways to tell a story. The basis of the book is the Hero’s Journey story structure and using it for messaging the brand experience of a business. What I didn’t see coming was the book teaching me a new way to frame a vision. Similar to using a postcard from the future, the hero’s journey is a fun way to express the vision. Whether describing how a product changes the lives of its’ users or how a person represents their own “badass” future, the hero’s journey is a great way to inspire and clearly express a direction worth heading.

If you are not familiar with the Hero’s Journey, in a very general sense, it goes something like this:

There is a character who is our hero, who has one or more problems and challenges that is keeping them from reaching their dreams. Our hero is joined by a guide who is a trusty confidant and wise advice giver that helps our hero to come up with a plan to overcome their challenges. Together, they spring into action to successfully overcome the problems and avoid the cost of failure. They emerge on the other end of their journey, having learned and ready for their next challenge together.

Step 1 – Establish the Character (a.k.a. Our Hero)

For this article, we are going to focus on how a team can use Story Brand’s hero’s journey structure to drive continuous improvement. So our character is going to be an Agile Team and let’s have a little fun and add some minor adjectives to describe the current state of the team. For the story, let’s call them the fledgling Code Avengers.

Step 2 – Describe the Challenges and Problems

A vital part of the hero’s journey is the challenges and problems the character is facing. Donald Miller identifies four sources of challenges:

  • Villain(s) – those who promote the failure of the hero — they may even actively work for the hero’s demise.
  • External – the forces that make the journey daunting, if not impossible.
  • Internal – things the hero might not be able to do either because of lack of skills or self-doubt.
  • Philosophical – the beliefs that challenge the hero or conflict the hero.

Not every hero faces these challenges, but these challenges or problems are what makes the story exciting.

The biggest challenge the fledgling Code Avengers face is that they were just formed and added to an existing significant initiative that has profoundly aggressive expectations. They are a team that is made up of several folks new to the organization and a few others plucked from parts of the organization. Fifty percent of the team have agile software development experience, and they all know very little about the capabilities that their product provides it’s users.

Step 3 – Identify the Guide (and Maybe a Sidekick)

All right, the next step on the hero’s journey is introducing an unlikely sidekick — someone who’s supporting the hero on their journey and acts as a guide. Now, the guide on the hero’s journey brings knowledge and insight and provides supportive direction that the hero can choose or choose not to, to follow.

In our continuing story of the hero’s journey, we give homage to Ally, our wise Scrum Master and guide. Ally has been with the organization for a while. She has the experiences necessary to help the Code Avengers to jump in and learn the processes and context of the users’ needs.

Step 4 – Plans and Knowledge, Shared and Gained

Now, it’s time for the sidekick or guide to shine. The next step in the hero’s journey is for insights to be shared by our guide and gained by our hero. These insights can come in the form of new ideas, plans, coaching, and mentoring — all focused on helping the hero overcome the challenges.

As the Code Avengers guide, Ally is planning for training to instill the basics of using Scrum as their operating model and work with the team to establish working agreements. Then, she and the team’s Product Owner will negotiate with another team working on the same initiative to get some work that the Code Avengers can immediately work on and deliver. The plan is that by doing valuable work right away, they would start getting insights into what the technology stack is like, and start learning about users’ needs.

Step 5 – A Call to Action

At this point in the hero’s journey, it is time for action — or as The Story Brand points out, it is “a call to action.” The guide and trusty sidekick, jump in working with the hero to nudge the hero to start tackling the challenges — confronting the villains and work hard to overcome internal and external problems. In doing so, the guide elevates the hero and helps the hero learn along the way. Every good hero’s journey has a point of inflection and aspects of learning that lead the hero to a new state of being.

Back to our own hero’s journey, Code Avengers is now working hard. Moreover, Ally, our guide, establishes a simple “badass” learning board that reflects on the team’s adoption of Scrum. Each of the Scrum events, including the daily scrum, sprint planning, and sprint review, are tracked until the team feels they’ve achieved mastery. In addition to this, the team tracks the feedback from the users. They work together with the users and learn quickly, building themselves as trusted partners in solving the users’ needs. The leaders of the initiative take notice and consult with the Code Avengers to best set expectations with the user community.

Step 6 – Arriving at Success and Moving On

So concluding the journey, the hero hopefully has success and avoids the pitfalls of doom. The guide and, possibly, the sidekick stand back with pride as the hero stands with a glow all around. So now, it’s time … to do it all over again and face the next adventure.

Hopefully, you enjoyed what you read here, and are inspired to try using the Hero’s Journey to express a vision. I encourage you to give it a go. I found The Story Brand book to be hugely helpful, and they have online tools and other learning resources that make it easy.

I’d love to hear your experiences and ideas, please share with comments below.

10 Ideas to Make Backlog Refinement Rock


Before we go through the ten ideas, it’s important to take note of two really important things — backlog refinement is a team sport and backlog refinement is continuous — not just one session every couple weeks. So although most of the ideas are focused on the backlog refinement session, the intent is to introduce ways that we can increase participation, make it easier to facilitate, and hopefully, greatly improve shared understanding.

  1. Be Prepared. Probably the most critical part of making any refinement session successful is being prepared. What does this mean, well maybe a checklist is in order:
    • Identify the top-x stories that are not “ready” and need refinement. Ideally, your backlog is ranked, and it’s the next items on the list.
    • Identify the questions for the team and invited subject matter experts.
    • Prepare any artifacts that will help the conversation around the stories (e.g., designs, user feedback, 3rd party specifications, etc.).
    • Send out the agenda with the list of stories to be covered and identify the preparation steps for the attendees.
    • Make sure that if you have remote people that you have identified the technologies that you will use (e.g., web meeting software, full-duplex phone, online brainstorming tool, etc.) and you’ve tested these out.
    • If there’s someone new or the meeting will be largely remote, plan to either start early or use the first few minutes to get everyone connected — set this expectation ahead of time.
    • Identify and confirm the facilitator and the approach for capturing notes and observations. Let’s not have all the great ideas and things we learn to escape into the ether.
  2. Design Storm. A Design Storm is a type of workshop that is usually associated with human-centered design and or design thinking where participants are asked to create a low-fidelity concept around an idea or problem a group is trying to solve. For a Backlog Refinement session, you can use this approach to get people who might not normally speak up, to get engaged in the process. Generally, participants will uncover great ideas, and discussions will ensue around complexity or “de-complexifying” the backlog item(s).
  3. Lo-fi Prototype. Create a low fidelity prototype and pass it around the room or have multiples created. Something as simple as sketches of the screen(s) and when someone “clicks” a button or enters a field, you can show another sketch or discuss content. You don’t have to be an artist or use some amazing (a.k.a. complex) UX mocking tool. Just use post-its and or normal letter (or A4) paper. When you use this approach, encourage folks to be critical and question everything, even if it’s an area where you tried to mark out a mistake. If you are wondering just what a low-fidelity prototype is, check out this article by Laura Busche.
  4. Oblique Strategies. Oblique strategies are a set of statements that are meant to create a challenging constraint to help increase creativity through lateral thinking. Okay, this one may seem a little odd for a backlog refinement session, but I’ve been witness to many sessions where the ideas to solve the user problems are mundane and more of the same — often being offered by the same 1-2 people in the room, over, and over, and over again. Oblique strategies can help the group try something new. Do a quick search on the app stores, and you’ll find an app that has oblique strategies listed. NOTE – some oblique strategies are to help musicians and might not make sense — go to the next one.
  5. G-W-T. Given-When-Then (a.k.a., Gherkin) is the product of Behavior-Driven development. GWT is an approach where as a team, we can use a structured language to talk about how a user [or system] may interact with a tool or piece of software to achieve their desired outcome. If you’ve never used GWT, you’ll find the structure to help drive some conversations and give clarity to the behavior the system without dictating the solution.
  6. SQUID. This acronym stands for Sequential Question and Insight Diagram. SQUID is a great approach to allow the group to ask questions and record the answers. It can be done interactively with the facilitator(s) capturing items, or ideally, there are a series of brainstorm moments where the team writes questions, and the knowing team member poses answers. The process repeats until the team has clarity for the backlog item. See the website for how to use this approach.
  7. Apply Lean Coffee. If you’ve never heard of Lean Coffee, it’s an approach to facilitating an open session of people. Generally based on a context, Lean Coffee provides a means by which to structure discussions through the use of a personal kanban board and time boxing (see for more information). For a backlog refinement session, instead of brainstorming and dot-voting topics — use the backlog items to be discussed. Applying the Lean Coffee structure does two things — (1) focuses the discussion on one item at a time and (2) it helps keep the conversation moving instead of getting stuck on one item for too long. When I’ve used this question in the past, the question around extending the time box was “Can we estimate this one yet? If not, do we keep talking? Or, does it need to go back with the PO for more discovery?”
  8. Story-walk. One thing that brain-science has made clear, our noodles are more engaged and work better when we move, and there’s some variety. A story walk is simple, print out the story details as it’s known today — make it big, so it’s easily readable. Give each person a pad of sticky notes and a marker. Ask them to walk around writing and posting Questions (?), Assumptions (!), Actions (*) and Ideas ($). Make sure they use symbols that make it clear what type of post they are submitting. Do this for 20 minutes, and then ask the team to re-walk the stories — this time clarifying and grouping similar items. After ten more minutes, focus on the questions, and get them answered. Hopefully, by the end of the session, you can do some quick affinity estimation or white-elephant sizing. A similar exercise as the story walk is doing a story workstation, where you set-up multiple tables with handouts containing details about each story. The ask is the same, but instead, the participants are moving table-to-table.
  9. Triad-up (a.k.a., Three Amigos). Have three people take a backlog item and gain an understanding of it. The three people should be made up of one with business knowledge, another focused on the question of “how to test?”, and another person focused on the question of “how to build?” These three amigos should do their best to get the backlog item to a point where they believe the team should be able to estimate it together. Get the room into triads, divvy up the backlog items, and give them a time box to discuss the backlog items. Leave 15-20 minutes for shared discussion and estimation at the end. To learn more about the Three Amigos (in context of agile software development) check out this article by George Dinwiddie.
  10. Re-baseline Understanding of Refinement. One thing we often do as humans is that we often extend our level of understanding what we believe others know about a topic. Well, if a team hasn’t been doing something for very long or that something they are doing hasn’t been very effective, then it’s probably time to practice something new. All that said, take the time to discuss the concept of refinement, the team’s role in refinement, how a refinement session should work, and the desired outcomes.

Testivus for the Rest of Us: A Whole Team Testing Experience


The Story

I want to share a true story of a relatively newly formed agile team. We were made up of ten engineers writing and testing code in C++, Java, and fully embracing the emerging javascript frameworks. The application we were building was both complex and complicated. We were learning how to launch a product, trying to embrace user-centric design, and honestly, I often screwed up as a lean agile leader. All that said, we were a pretty great team and we were constantly learning.

We were in the midst of a new product release that was careening towards a GA date. The testers on our team — who were pretty great at what they did — were getting pressed against that GA date with the build-up of feature inventory. As a team, we were doing an okay job at establishing automation, but we could do more — a lot more. So with the testers in the needs of some aid and the need to shift left more testing, we arrived at Testivus for the Rest of Us.

How It Started

As a team, we often themed our sprints. Sometimes these sprint themes were merely broad brushed sprint goals. We already had the “Unleash the fury, Mitch” sprint in which we literally sprinted to the finish line several key product features. In need of raising our game around test automation and in general, switch the team from a “test right” to “test left” where quality was truly the starting point of all work — we decided to theme a sprint “Testivus.” What better theme than Testivus — time to air our grievances and demonstrate feats of strength.

[su_note note_color=”#fdfdce”]NOTE: In case you’re not a Seinfeld fan, Testivus is a play on Festivus. See Festivus – Wikipedia for more information.[/su_note]

In preparation, we built the sprint backlog around those items that needed the most attention (we looked at a heat-map of components based on bugs previously found, code complexity, and skeletal impact to the product). This backlog wasn’t just a bunch of technical stories, we focused on the functional areas and created functional validation stories that restated the user outcomes, and we refined the acceptance criteria based on usage validation (as well as early learning from the field – e.g., performance needs, essential data needs, etc.). Some may call this just a regression backlog, and that’s fair; however, our mindset was different — it was all about outcome validation and, to some extent, validation that the product we were making was innovative and would kick-ass in the minds of our prospective users. Also, to note, this wasn’t about a “Hardening” sprint. You could argue this; however, we weren’t at the end of the release, and our core goal was to bring testing left in the cycle.

Once we built the stories and the resulting tasks included fleshing out a test harness, more in-depth unit testing practices and practicing TDD, functional UI test automation, and refining our CI process to extend into CD including bootstrapping test and demo data creation.

The Results of the First Testivus

The tangible outcomes were:

  • Stronger installation and deployment automation including packaging.
  • A robust test data generator and demo data bootstrap.
  • A new & improved test harness that handled both functional aspects as well as continuous performance benchmark validation. The harness covered over 1,800 scenarios nightly.
  • Increased code coverage from single digits to a substantial double-digit percentage.

The most impactful outcome was that team’s mindset which was already pretty good, became hyper-focused on how quality should be built-in. From this point forward, during refinement, the first thing we would talk about is attributes of testing.

The Longer Term

Testivus became a regular occurrence in the context that we called for a “Testivus” day or two every 5-6 sprints. Sometimes the need surfaced when we noticed a trend of bugs in a particular area, field feedback, and a couple of times we “Testivus” as part of a quality hack day.

Reflecting on Testivus, there was a need and the theme was awesome. It changed our mindsets, we had some focused energy on quality, and we had some fun — even though it was intense at times.

The great thing is — this concept wasn’t unique to us. Sometimes teams need a cause and a theme to try something new, and this helped us gel around some learning of good practices.

A couple of years later I joined VersionOne where the development team adopted “meatfest” which was a bug bashing event that had the team grilling out meat and vegetables, and drinking some beer throughout the day — all the while just fixing a bunch of stuff (I would point you to the awesome blog on this topic, but someone took it down).

Please let me know if you have experienced the same or would like to discuss further. Thanks for reading!

Update: We definitely weren’t the only one’s going down the Testivus path — just Google “Testivus.”

An Agile Team Task by Any Other Name – A To Do


Let me first say, I know the idea of task decomposition is fairly well covered and some might call it a basic practice of any team; however, as a coach helping teams to adopt agile software development, I don’t always see teams finding this practice of defining “how to get to done” as a natural team planning activity. Instead, I see teams getting frustrated with a clunky approach or a high-level of disengaged team members or a member of the process police controlling the meeting that is distinctly a team meeting or I still see the “lead” define the tasks and simply dole them out.

Defining “How” to get stuff done as a team should be the straightforward activity around software development. It should be an engaging activity of brainstorming, learning, sometimes arguing, and ultimately a good feeling of “let’s git’r done.” All-too-often it seems like a torture technique riddled with challenges. These challenges are often rooted simply in poor practices, some of the which include:

  • Creating faux work breakdown structures (yes, I said it — WBS) of standard tasks (e.g. each story has “Design”, “Code”, “Review”, “Test”, “Deploy” tasks). Some would argue this is not a poor practice, but tasks should have context and be relative. Not to mention, this is kinda mundane, requires no thought, and is flat out lazy and contrived.
  • Focusing on the accuracy of hour level estimation. If we are consistent with relative estimation and looking at cycle time, we can come up with the “low risk” and lean approach to determine which stories to work on. Estimation at this level is more of a measure of certainty.
  • Creating tasks and tests that are ginormous — like a 40 hour task for a two week iteration. If someone tells me that it’s going to take 40 hours, then I view that as high risk and we need to keep talking about it to better understand it.
  • On the other hand, creating micro tasks — yes, so many that the Task board looks like like a sticky note factory exploded on the wall or invoke pagination within the tool.
  • Having the developer and tester creating tasks and tests in isolation without any conversation with each other or the rest of the team.
  • Oh yeah, let’s not forget when I get asked about reports that measure how underutilized people might be. Often the focus of understanding “How” becomes simply an exercise to maximize utilization.

That last point about utilization, it seems like a frequent driver of the planning exercise. It’s odd in that sometimes people think that if we don’t have a plan with everything defined that we are going to do before we go do it; well — when the stuff we do get done is complete, we’ll simply stop working and sit there and stare at each other. I’m pretty sure that this is never the case and if it is, either get new people or look in the mirror.

Does any of this sound familiar? Does any of this frustrate you?

Well, I have a few ideas for you to try — most of these are common sense and talked about by others, but it’s always good to mix it up and try something different to get out of the rut or remove the pain associated with planning.

First, abandon planning using ideal hours — I know, I’m crazy — but hear me out. The common rule for any to do or task is that it should take no more than a day to get completed, ideally less. Tobias Mayer’s book called The People’s Scrum contains a curated set of his past blog posts, one in particular called, “When is Scrum not Scrum?” explains his reasoning for non-estimated, day or less tasks — (1) eases tracking – just burndown tasks — the burndown is number of remaining open tasks and (2) it helps to unearth unforeseen impediments that are often just part of what we normally do. While these are great, I would add that focusing on estimates and accuracy of the estimates actually just results in taking the eye off quality and flow of value.

Next, decompose just enough stories to commit to the goal and get started. The Scrum Guide is pretty clear about this:

… enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting.

Now, new teams may need to decompose all stories during a sprint planning, but teams that have been together for a while may be able to quickly determine what stories to do in the next two weeks, how they fit a incremental goal, and then just go. Don’t make your sprint planning meetings more painful — if you are planning for 2 hours and you have enough work to start the sprint, then go start.

Try different techniques for this meeting that encourage engagement. For example:

Taskstorming. A simple approach where the team selects which stories they are going to work on based on past velocity and then, interviews the Product Owner on each. During the interview, the teams is noting on sticky notes the tests and tasks. Once a goal emerges, then it’s time to task [and test] storm. On a whiteboard, write the title and draw a large box for each story. Now have the team place their stickies up on each story. Duplicates can be discussed as well as someone can put up something that doesn’t make sense to anyone else — well discuss it. Through this process, let the conversations flow – observe a story with a ton of task, then maybe it should be broken apart? Taskstorming not only makes the meeting more efficient, but it’ll make it more effective because everyone is involved and engaged in the process. At the end, have folks pair up and help get the data captured in your favorite tool (which means VersionOne).

Other techniques you can try include Task-n-Tell and Test First Tasking.

Finally, as I’ve mentioned in a couple past blogs, put this on the team – this is a team activity. If you are a team member, take ownership of this meeting and you lead it. The Scrum Master or Lead or Facilitator of the team would typically do this, but if you find them directing or assigning tasks out without engagement. Well you have a problem and the best way to change it is for a team member to take over. If you are a Scrum Master or Lead and you are struggling with getting the team engaged, try something new — don’t be insane. Try introducing a facilitation game or asking someone else to facilitate (not the product owner or anyone else in a position of authority).

No one should suffer through a sprint planning meeting. Yes they can be hard, but they shouldn’t be torture — so, inspect and adapt. Time to make them fun and effective.

Remember that at the end of the day, tasking is simply defining the proverbial To Do list to get a story done.

Cold Day = Bacon, Black-Bean Chili

Well it is very cold outside — even in Atlanta, Georgia.  When it’s cold — it’s time for one of our favorite household recipes which is Bacon, Black-Bean Chili.  If you happen to be a chili fan, this is a recipe you’ll love.  I usually add some extra jalapeno and every once in a while, I’ll inlcude smoked brisket as the meat.

Here’s the recipe from  And here’s a good one for the brisket style from

1 2 3 14