///

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

Keep Reading

LEADERSHIP

10 Ideas to Make Backlog Refinement Rock

//
Backlog Refinement

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 GameStorming.com 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 leancoffee.org 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.
     

You might be interested in

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

///
Happy Testivus

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

You might be interested in

Problem Solved: Formula to figure out How Much Detail is Required with Agile Requirements

/
Documentation Formula

[su_note note_color=”#fdfdce”]WARNING: Shameless plug for my session at Agile2014 ahead.[/su_note]

I recently got the priviledge to listen to Alistair Cockburn talk to a small group at the VersionOne offices. He told the story about Kent Beck and how the idea of how the user story on notecards was born (I’ve read about this before, but it was great hearing it from Alistair). He talked about how the card was just that — a card with a title that reminded the developer and the target customer/user what they were building, maybe there were a few notes jotted down on the card. The narrative about the story wasn’t captured on the card — the details were verbally communicated because the developer and customer were all in close proximity of one another — they did this crazy thing, they simply walked down the hallway and talked.

In addition to this story, Alistair spoke about his experiences with a team that had development in Singapore and the business folks and architecture worked in the states. The company was having challenges with the team in Singapore at getting things done efficiently and, in some cases, getting things done right. It seemed like there was an inordinate amount of time that had to be spent on discussing requirements and getting questions worked out. The company decided to send some of the business and architect team members to Singapore to work out some improvements. When they did — the quality and productivity went up. When they returned, it took just a couple weeks before productivity slipped and all gains were lost. The reason for these results seems obvious — timezones, communication barriers, and not being able to have impromptu conversations can have a great impact on how well teams understand the requirements especially since a lot of conversations capture the specifics.

Hearing these two stories triggered some ideas in my head, and I thought — why can’t there be a simple formula we can use to gauge the amount of detail (words) we capture in a story to make it work. Through some hard work — I’ve now have that formula.

Here are some factors that I think go into figuring this out:

  • Complexity – just how well does the team understand the story and how hard the team thinks it will be, either from experience or flat out guessing. Usually captured as story points.
  • Difference in Timezones – the number of hours that separate us greatly impacts how fast communications can happen, especially if the communications occur near the bookend points of the day.
  • Auditing Requirements – audits are generally costly and require an additional amount of documentation overhead.
  • Multiple Offices – when people are in different buildings, it raises the amount of details that have to be captured.
  • Offices on Different Continents – although this somewhat relates to timezones, there is also the fact that people speak different languages. Even if they all agree to use english as the primary business language, there’s still slang, accents, and even cultural differences that impact communications.

How Long the Team has Worked Together – knowing each other is key, we figure out accents, we are able to exchange less verbal words, and we learn how to work with one another — what level of information is required to work effectively as a team.

So I reached out to some friends and the folks at Tagri Tech, and with their help — here’s the formula we came up with:

Amount of Words in Story = (Complexity * (1+ max absolute difference between timezones) * (1 + # of annual audits) * (Total # of locations * # of continents)) / (# of quarters the team has worked together)

And here’s the formula in action:

Documentation Formula

Multiple simulations have been ran and I found that the formula works in less than 0.01% of the situations. The people I’ve been working with at Tagri Tech’s statistics analysis department have ascertained that every team is different, and every product is different — this means that no matter how much documentation you have — the people involved in creating the documentation or the target consumer of the documentation really are not going to read it. They found that while some documentation like compliance reporting and end user documentation are necessary, much of the collaboration level docs are only consumed by the person that created it.

Ultimately, Teams will generally work together to figure out how much details are truly required to facilitate working effectively. If your teams are having challenges with how much documentation is required within Agile Software Development projects, then please come to Agile 2014 and check out my session on Friday at 9AM in the Sanibel room, we’ll talk about some ways teams can workout their own formula.

You might be interested in

1 2 3 … 19

BACON