Prioritise we Must

Over on the Agile in the Ether Slack instance one of the Ethernets recently asked:

MoSCoW: Does anybody have a simple way of explaining when items should be Must vs. when they should be Won't? Is it really as simple as whether it's an inclusion or an exclusion of the item?

MoSCoW is a basic approach to grouping project project work into buckets graded by priority:

M: must have
S: should have
C: could have
W: won’t have (for now)

I'm sure every one of us has been in conversations where the buckets are filled and then stakeholders say they're all emergency-level important, but that's not today's problem. In this case the questioner had been burned by people twisting the words in unhelpful ways: "must not do ..." (i.e. won't) or "won't do without ..." (i.e. must) which only makes the often fraught prioritisation discussions even less pleasant.

I have found MoSCoW to be useful so I shared an example...

We had several vague and underspecified but clearly overlapping "products" (really potential product variants with different feature sets) being spoken about, all built on top of a new service. The development team was being asked about "production readiness" of the service but struggling to give an answer because it depended on the particular product it should support and the questioner's idea of that product's scope.

I wanted to expose the problem and increase clarity for all sides so I made a Miro board with a table structure: "products" across the top and features/fixes/ideas down the left. Stuff we were already working on or had just finished was at the top, stuff we'd recently suggested was next, stuff that'd been hanging around unimplemented for a while at the bottom.

Next I seeded the table by adding stickies for MoSCoW categories on the recent work and some of the ancient backlog. We had never made explicit MoSCoW decisions on those things, but enough had been said and done that I could pull out our implicit choices.

In the session with a couple of developers, an architect, and the PM of the team I:

explained basic MoSCoW
said that I favoured breadth over depth in the session, to map the product/feature space
said that I would facilitate to achieve that breadth
added another category "need more information" to use anywhere there was not relatively quick consensus

To set the context I walked through the tickets I had seeded, explaining why I was using which MoSCoW category and asked the participants to challenge, query, object, etc. I think this is probably the one-line answer to the original question: I demonstrated how the categories align with what we were already doing to establish some kind of shared understanding.

During the conversation, if someone used a phrase like "we should ..." or "it would be nice if ..." I'd cry

You used the magic words!

and make a sticky for the feature/product variant under discussion (should and could respectively for those examples).

This perhaps also relates to the original question: I took the natural way that participants expressed their position and mapped it to the categories. (Credit: this technique was a favourite of a great dev manager I worked with, Jason Trenouth.)

The outcome of the session was a board with:

some "need more information" areas for the PM to focus on, within and outside the team
some clear "valuable" features that are universally required
additional requirement information that hadn't been visible previously
some stuff that we can not do for now, because a product variant is said to not need it

MoSCoW won't solve all your prioritisation problems but I find that it can be a valuable filter for sorting things into buckets for further refinement. In this exercise that was a useful outcome but so was the set of "need more information" areas, not to mention the conversation itself.

One final thing: I was careful to make it clear that we had only categorised the features and fixes that I had pulled from our backlogs, and that we'd only made preliminary decisions on them given what we knew at that point. No-one should regard the board as either complete or a schedule because we'd find things out along the way, as we always must.
Image: Neil Mewes on Unsplash

Comments

The Best Programmer Dan Knows

I was pairing with my friend Vernon at work last week, on a tool I've been developing. He was smiling broadly as I talked him through what I'd done because we've been here before. The tool facilitates a task that's time-consuming, inefficient, error-prone, tiresome, and important to get right. Vern knows that those kinds of factors trigger me to change or build something, and that's why he was struggling not to laugh out loud. He held himself together and asked a bunch of sensible questions about the need, the desired outcome, and the approach I'd taken. Then he mentioned a talk by Daniel Terhorst-North, called The Best Programmer I Know, and said that much of it paralleled what he sees me doing. It was my turn to laugh then, because I am not a good programmer, and I thought he knew that already. What I do accept, though, is that I am focussed on the value that programs can give, and getting some of that value as early as possible. He sent me a link to the ta...

Meet Me Halfway?

The Association for Software Testing is crowd-sourcing a book, Navigating the World as a Context-Driven Tester , which aims to provide responses to common questions and statements about testing from a context-driven perspective . It's being edited by Lee Hawkins who is posing questions on Twitter , LinkedIn , Mastodon , Slack , and the AST mailing list and then collating the replies, focusing on practice over theory. I've decided to contribute by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me? --00-- "Stop answering my questions with questions." Sure, I can do that. In return, please stop asking me questions so open to interpretation that any answ...

Beginning Sketchnoting

In September 2017 I attended Ian Johnson 's visual note-taking workshop at DDD East Anglia . For the rest of the day I made sketchnotes, including during Karo Stoltzenburg 's talk on exploratory testing for developers (sketch below), and since then I've been doing it on a regular basis. Karo recently asked whether I'd do a Team Eating (the Linguamatics brown bag lunch thing) on sketchnoting. I did, and this post captures some of what I said. Beginning sketchnoting, then. There's two sides to that: I still regard myself as a beginner at it, and today I'll give you some encouragement and some tips based on my experience, to begin sketchnoting for yourselves. I spend an enormous amount of time in situations where I find it helpful to take notes: testing, talking to colleagues about a problem, reading, 1-1 meetings, project meetings, workshops, conferences, and, and, and, and I could go on. I've long been interested in the approaches I've evol...

How do I Test AI?

Recently a few people have asked me how I test AI. I'm happy to share my experiences, but I frame the question more broadly, perhaps something like this: what kinds of things do I consider when testing systems with artificial intelligence components . I freestyled liberally the first time I answered but when the question came up again I thought I'd write a few bullets to help me remember key things. This post is the latest iteration of that list. Caveats: I'm not an expert; what you see below is a reminder of things to pick up on during conversations so it's quite minimal; it's also messy; it's absolutely not a guide or a set of best practices; each point should be applied in context; the categories are very rough; it's certainly not complete. Also note that I work with teams who really know what they're doing on the domain, tech, and medical safety fronts and some of the things listed here are things they'd typically do some or all of. Testing ...

Don't Know? Find Out!

In What We Know We Don't Know , Hillel Wayne crisply summarises a handful of research findings about software development, describes how the research is carried out and reviewed and how he explores it, and contrasts those evidence-based results with the pronouncements of charismatic thought leaders. He also notes how and why this kind of research is hard in the software world. I won't pull much from the talk because I want to encourage you to watch it. Go on, it's reasonably short, it's comprehensible for me at 1.25x, and you can skip the section on Domain-Driven Design (the talk was at DDD Europe) if that's not your bag. Let me just give the same example that he opens with: research shows that most code reviews focus more on the first file presented to reviewers rather than the most important file in the eye of the developer. What we should learn: flag the starting and other critical files to receive more productive reviews. You never even thought about that possi...

My Adidas

If you've met me anywhere outside of a wedding or funeral, a snowy day, or a muddy field in the last 20 years you'll have seen me in Adidas Superstar trainers. But why? This post is for April Cools' Club . --00-- I'm the butt of many jokes in our house, but not having a good memory features prominently amongst them. See also being bald ("do you need a hat, Dad?"), wearing jeans that have elastane in them (they're very comfy but "oh look, he's got the jeggings on again!"), and finding joy in contorted puns ("no-one's laughing except you, you know that, right?") Which is why it's interesting that I have a very strong, if admittedly not complete, memory of the first time I heard Run DMC. Raising Hell , their third album, was released in the UK in May 1986 and I bought it pretty much immediately after hearing it on the evening show on Radio 1, probably presented by Janice Long, ...

Not a Happy Place

A few months ago I stopped having therapy because I felt I had stabilised myself enough to navigate life without it. For the time being, anyway. I'm sure the counselling helped me but I couldn't tell you how and I've chosen not to look deeply into it. For someone who is usually pretty analytical this is perhaps an interesting decision but I knew that I didn't want to be second-guessing my counsellor, Sue, or mentally cross-referencing stuff that I'd researched while we were talking. And talk was what we mostly did, with Sue suggesting hardly any specific tools for me to try. One that she did recommend was finding a happy place to visualise, somewhere that I could be out of the moment for a moment to calm disruptive thoughts. (Something like this .) Surprisingly, I found that I couldn't conjure anywhere up inside my head. That's when I realised that I've always had difficulty seeing with my mind's eye but never called it out. If I try to imagine ev...

Going Underground

The map is not the territory. You've heard this before and I've quoted it before . The longer quote (due to Alfred Korzybski) from which the snappy soundbite originated adds some valuable context: A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness. I was thinking about that this week as I came to a product new to me but quite mature with a very rich set of configuration options. When I say rich , I mean — without casting any shade, because I have been there and understand — it is set in multiple locations, has extensive potential effects, and is often difficult to understand. For my current project I consider it crucial to get a non-shallow view of how this works and so I began to explore. While there is some limited documentation it is, as so often, not up to date so mostly I worked in the codebases. Yes, plural, because this product spans multiple r...

Notes on Testing Notes

Ben Dowen pinged me and others on Twitter last week , asking for "a nice concise resource to link to for a blog post - about taking good Testing notes." I didn't have one so I thought I'd write a few words on how I'm doing it at the moment for my work at Ada Health, alongside Ben. You may have read previously that I use a script to upload Markdown-based text files to Confluence . Here's the template that I start from: # Date + Title # Mission # Summary WIP! # Notes Then I fill out what I plan to do. The Mission can be as high or low level as I want it to be. Sometimes, if deeper context might be valuable I'll add a Background subsection to it. I don't fill in the Summary section until the end. It's a high-level overview of what I did, what I found, risks identified, value provided, and so on. Between the Mission and Summary I hope that a reader can see what I initially intended and what actually...

Heads Up

I tell you what: of all the things I might've expected to see on the first slide at Quality Jam London 2017 , my own professional-work-photo-grinning, shiny-pated, blue-tinted face peering back down at me from behind a massive Thank You! wasn't it. Expectations are grist to the working tester's mill, yet also often the bane of their lives. Tony Bruce , in Manual Testing is Dead. Long Live Manual Testing , called for testers to set the expectations of the people that they interact with. The term "manual testing" undersells what testing is, or can be, with its connotations of manual labour, unthinking monotony, apparent separation from (woo! sexy!) automation and the historical association with scripted test cases. For Bruce, testing is "the pursuit of information" but he doesn't necessarily rush into meetings spouting from that kind of lexicon (although he's singing my kind of song right there). Instead he promotes the use of PAC (purpos...

Hiccupps

Search This Blog