Category Archives: User Stories

Minimum Viable Product Manager

29 Wednesday Aug 2018

Posted by in Agile, Agile2018, Approaches, Context, Experiments, Metrics, Protip, Retrospective, Scrum, Soft Skills, Training, User Stories

≈ Leave a Comment

At Agile2018, I attended Richard Seroter’s Product Ownership Explained session, where I heard about bad and good product owners. Product ownership/management has many facets including

  • advocating processes and tools
  • style of leadership
  • customer interactions
  • relationship with engineers
  • approach to continuous improvement
  • product lifecycle perspective
  • sourcing backlog items
  • decomposing work
  • running through a sprint
  • meeting involvement
  • approach to roadmap
  • outbound communication

Now I’ve been working alongside many customer proxy team members (e.g. business analyst, product owner, product manager) over the years. I’ve learned how to create testable, executable, deliverable user stories in a real-world setting. I wasn’t going into this talk blind. I just haven’t always focused on the Product role.

This time, I looked at the role with the mindset of what it would take for me to check all the boxes in the “good” list. As each slide appeared, my list of TODOs lengthened. I started to feel overwhelmed by the number of things I wanted to improve…

“How you doin’, honey?” “Do I have to answer?!?”

I walked out of that talk thinking I’m not sure I want to sign up for this epic journey. The vision of the idyllic end state was more daunting than inspiring. How could I possibly succeed at this enormous task? Would I want to sign up for that? My initial reaction was no! How could I take on all the technical debt of stretching into a new role like Product? How long would the roadmap to “good” take?

Analysis

When I evaluate things off the cuff, I often consider good-bad-indifferent. Maybe knowing what “good” and “bad” look like wasn’t helping me. I knew I didn’t want to be merely “indifferent”… maybe what I really wanted to know was this:

What does a minimum viable product manager look like?

One of my big takeaways from Problem Solving Leadership (PSL) with the late, great Jerry Weinberg was limiting work in process (WIP) or “one thing at a time” (as close to single piece flow as possible) improves effectiveness. If I take that approach to a PO/PM role, I’m afraid that I would completely fail. So I will reduce the practices to as few as I possibly can without completely losing the value of the role. I want only the *critical* path skills or capabilities! Everything else can be delegated or collectively owned or done without. So what can I discard?

In this thought experiment, I’m proposing finding the least possible investment in each essential aspect of the PO/PM role that would move from bad past merely indifferent to viable (but only just!). I needed to reduce my expectations! If I allow minimum viable to rest somewhere in my default scale, then it fits between indifferent and good. That means I deliberately do *not* attempt to inject all of the good practices at once. So let’s revisit the axes of expertise and the lists of behaviors that are good and bad…

What’s the least I could do?

Decomposition

Advocating processes and tools

Good: contextual & explanatory & collaborative (fitting process to team + pragmatic tool choices + only important consistency + explains process value + feedback leading to evolving)
Minimum viable: pragmatic minimalism (choose a simple process & let practices earn their way back in as value is explained + choose an available tool + allow consistency to emerge + request feedback)
Indifferent: status quo (follow existing process/ceremony w/o questioning + let others choose tools + don’t justify)
Bad: dogmatism (one practice fits all + adhere to ceremony + prescribed toolchain + standardization + trust process + don’t justify)

Style of leadership

Minimum viable: leads by example (models behaviors for others without trying to modify their behaviors) + doesn’t worry about respect + consultative decisions + experiments/loosely decides + sometimes available to the team but not constantly + flexible + defaults to already available metrics

Customer interactions

Minimum viable: meets with customers at least once + builds casual relationship with a key customer + gets second-hand reports on Production pain + occasional customer visit + default information sources

For me, this one slides a bit too far toward indifferent… I’m not sure how little I could care about customers and still get away with being acceptable at PO/PM…

Relationship with engineers

Minimum viable: physically co-locates when convenient + T-shaped when it comes to the technical domain (i.e. aware but not trying to develop that skill as an individual contributor) + attends standup + shares business/customer/user information at least at the beginning of every epic + champion for the product & trusts everyone on the team to protect their own time

Approach to continuous improvement

Minimum viable: default timebox + takes on at most 1 action item from retrospective, just like everyone else + plans on an ad hoc/as needed basis (pull system) allowing engineers to manage the flow of work to match their productivity + prioritizes necessary work to deliver value regardless of what it’s called (bug, chore, enhancement, etc)

Product lifecycle perspective

Minimum viable: tweaks customer onboarding in a small way to improve each time + cares about whole cross-functional team (agile, DevOps, etc) + asks questions about impact of changes + allows lack of value in an existing feature to bubble up over time

Sourcing backlog items

Minimum viable: occasionally talks to customers + cares about whole cross-functional team (including Support) + backlog is open to whole team to add items that can be prioritized + intake system emerges + tactical prioritization

I do have twinges about the lack of strategy here, so I guess I’m looking at this part of minimum viable Product *Owner* (i.e. the mid-range focus that Richard points out in his 10th slide).

Decomposing work

Minimum viable: progressive elaboration (i.e. I need to know details when it’s near term work and not before) + thin vertical slices and willing to leave “viable” to the next slice in order to get a tracer bullet sooner + trusts the team to monitor the duration of their work & to self-organize to remove dependencies (including modifying story slicing)

Running through a sprint

Minimum viable: doesn’t worry about timeboxes (kanban/flow/continuous/whatever) + focus on outcome of each piece of work (explores delivered value) + releases after acceptance (maybe this is just continuous delivery instead of continuous deployment, depends on business context)

Meeting involvement

Minimum viable: collaborates with team members to plan as needed (small things more often) + participates in retrospectives + ongoing self-study of PO/PM

Approach to roadmap

Minimum viable: priorities segmented by theme + roadmap includes past delivery/recent accomplishments + adjusts communication as needed/updates for new info + flexible timeline in a living document + published roadmap accessible to all stakeholders on self-serve basis

Outbound communication

Minimum viable: allows org to self-serve info + shares priorities with manager & customers + environment for continuous self-demo/trying features + transparency

What are the minimum viable versions of the tools of a product owner?

  • Backlog – list of ideas not fleshed out until it’s time to run them
  • Sprint planning – ad hoc meetings in a pull system initiated by the need for work definition to execute
  • Roadmap – technical vision of system capabilities + compelling story of the product value proposition
  • Prototyping, wireframing – whiteboard pictures + text-based descriptions
  • Team collaboration – a big TODO list that everyone can access
  • Surveying/user testing – chat program that both team & user can access
  • Analytics – NPS score informally collected from customer conversation
  • Product visioning – I think this goes in with Roadmap for me?

So I’ll agree that the PO/PM role is critical and necessary. I would like for creative problem solvers to fill the role – and to be fulfilled by the role! In order for that to be viable, for people to grow into a Product role, there needs to be education on how to begin – and it can’t be spring-fully-formed-from-the-head-of-Zeus! Christening someone PO/PM doesn’t endow them with sudden wisdom and insight. Skill takes time to develop.

Set realistic expectations for beginners. Help teams to welcome people to grow in the role by offering both challenge and support from all the team members. As with any team need, the agile team has collective ownership to solve the problem, not relying on a single point of failure in the role specialist. Having a beginner PO/PM is an excellent time to reinforce that!

Don't worry, people. I so got this!

If I were a Product Manger, I would definitely prefer to be a full-featured representative of that specialization! However, I encourage you to revisit Richard’s presentation and do your own decomposition of the Product role. What is absolutely essential? What can you do without?

What is *your* minimum viable Product Manager?

Testing For Humans? Try Empathy

11 Friday Oct 2013

Posted by in Context, Experiences, Experiments, Personas, Skype Test Chat, Soft Skills, Test Retreat, User Experience, User Stories

≈ 1 Comment

sympathy-empathy
Two months ago, Matt Heusser organized Test Retreat and I attended, along with 27 other testers open to new ideas and wanting to change the world. Sound a little ambitious? Let’s find out!

My first blog post in this series is about Michael Larsen‘s Testing For Humans, which he was unable to live blog due to presenting. 🙂 However, Michael did post Alessandra Moreira‘s notes in his live blog of the event.

Fortunately, I was able to live-tweet the talk that he described as:

Testing for Humans: It’s Sticky, Messy and Very Satisfying

Abstract: Software development is a beautiful thing. We often create amazing ideas and features that would be wonderful… if only those pesky humans that end up using, abusing, and mis-understanding our brilliant code weren’t part of the equation. Unfortunately, we’re all in the business of developing software for people (yes, even when it’s machine to machine communication, it serves human beings somewhere. What are some ways that we can approach testing software outside of the theoretical ideals, and actually come to grips with the fact that real human beings will be using these products? How can we really represent them, test for and on behalf of them, and actually bring in a feature that will not just make them happy, but represent the way they really and actually work, think and act?

Expected Deliverables: An excellent debate, some solid strategies we can all take home, and some “really good” practices that will be helpful in a variety of contexts.

My take-aways were:

    • People are imperfect so ideal users aren’t enough for testing.
    • By definition, a composite of many people (e.g. user persona) is a model.
    • Too many user descriptions based on small differences is overwhelming, not practical for testing.

On Wednesday night of this week, I joined Christin Wiedemann‘s regularly scheduled Skype test chat with some other lovely wonderful tester folks and we focused on empathy in testing. We wrestled our way to some working definitions of empathy and sympathy, which was much better than shallow agreement though it took a bit of time to establish. We agreed that testers need to observe, focus on, and understand users in order to serve them better. We find that empathy for our users and passion for our testing work go hand-in-hand since we care about helping people by producing good software.

Then we struggled with whether empathy is an innate trait of a person testing or whether empathy is a learnable skill that testers can develop through deliberate practice. (Go watch the video behind that link and come back to me.) We concluded that knowing what others are thinking and feeling, getting inside their skins, in the context of using the software is essential to good testing, though this might require a bit of perseverance. This can go a long way toward avoiding thinking we have enough information just because it’s all we know right now.

As I mentioned in the chat, I’ve found that user experience (UX) design is an amazing ally for testers. One tool that helped me to develop more empathy for my users is user personas. (Later, I found that forming user personas of my product teammates helped me to develop empathy for them as well.)

I immediately took to (end) user personas as a natural progression from user stories. After all, user stories are focused on value to and outcomes for a particular group of users. Describing those users more specifically in a user persona dovetailed nicely. Rather than some sterile requirements that never name the user, identifying a role – or, even better, a rich symbol such as a named primary persona – focuses the product team’s efforts on serving someone by helping us to understand the purpose of the work we do.

We also discussed interviewing users, visits to users, and experiential exercises as techniques to help us call upon empathy when we are testing. In my work history, I’ve been fortunate to hear about my UX team’s great work in a collaborative design workshop, to contribute to designing ad hoc personas for my product, to participate in a UX-led contextual inquiry, and to log actual usability sessions led by my product team’s UX designer. (Yes, my fast fingers came in handy. Yuk yuk.) My innovation days team developed a usability logging product that evolved from an existing solution I tested/used in those usability sessions, so I was a natural fit to test it. I’m curious about empathy maps but haven’t tried them myself yet.

It’s fair to say I’m a UX-infected tester. More than fair. I identify with the curiosity I see in the UX profession and I admire the courage to kill their darlings (carefully crafted designs) when evidence shows it is time to move on. After all, we’re not building this product to marvel at our own cleverness but instead to serve humans.

Image credit

What I Did For My Summer Vacation – Part 1

31 Wednesday Jul 2013

Posted by in Acceptance Criteria, Agile, Approaches, Context, Experiences, Experiments, Retrospective, Soft Skills, Testing Humor, User Stories

≈ Leave a Comment

With the First Day of School quickly approaching, it’s time for:

What I Did For My Summer Vacation – Part 1

Exploring Requirements

I get really excited about hanging out with people, especially friends, especially a combination of new and old friends. So it was with great happiness that I set about organizing a geek gal weekend.

Our first conversations centered around budget (fixed), deadline (fixed), and features (flex). We started talking over the various activities that different destinations could provide to entertain us. Then, I paused the conversation to bring the focus back to value: when we looked back on this weekend, how did we want to remember it? how would we feel about the way we spent that time together? would features even feature in these stories we would tell? Instead of features, we realized that functions (what the product was going to accomplish) and attributes (characteristics desired by the clients) mattered more. (Why yes I was reading Weinberg this morning. How could you tell?)

Vintage gold lamé (see that gaw-jus totally 80s animal-print metallic finish? oh yeah.)

Vintage gold lamé (see that gaw-jus totally 80s animal-print metallic finish? oh yeah.)

We wanted to relish the simplicity of being together, whether wearing goofy vintage clothes (gold lamé for the win!), cooking our own meals together, telling silly stories, or engaging in feminine activities with a geek spin (magnetic nail polish was not as simple as expected) that would be low-key and more about togetherness than busyness. We wanted to craft something lasting (collaborative artwork – packing the craft supplies was a must not a want!) and reinforce durable friendships that appreciated our differences.

With this clear focus in mind, suddenly the locale was much less important than inclusivity to maximize togetherness.

Planned For Sand

So we made an informal backlog of tasks to tackle researching options (beach vs mountains), reviewing results, and prioritizing options (beach!) before presenting our findings to the group for dot voting. (Typical agilists, I’m tellin’ ya.) Fortunately, we found a viable approach and went forward with making arrangements to execute this solution (road trip!), adjusting as we went to accommodate discovered needs.

How did it all turn out? Stay tuned for scintillating tales of laughter and danger in What I Did On My Summer Vacation – Part 2!

Ash-ceptance Criteria

29 Monday Apr 2013

Posted by in Acceptance Criteria, Approaches, Context, Testing Humor, User Stories

≈ Leave a Comment

Ash-2Weapons
Someone asked me for examples of testable acceptance criteria… Alright. Who wants some?

User story:
As Ash, I want to defend myself against deadites (undead creatures) so that I can retrieve pages from the Book of the Dead.

Acceptance criteria:
– defend from a distance
– defend at close range

Two distinct pieces of value, huh? Clearly, we need a story split here!

User story:
As Ash, I want to repurpose the stump of my right arm into a fearsome weapon so that I can defend myself against undead creatures at close range.

Acceptance criteria:
– portable
– well supported, weight-balanced
– hands-free operation
– use available materials
– holds up under stress
– close-range fighting

Technical implementation:
– leather harness
– chainsaw mounted on handcuff
– chainsaw pull operated via bracket on harness

User story:
As Ash, I want another weapon for my left hand so that I can defend myself against undead creatures at a distance.

Acceptance criteria:
– portable
– easy storage
– one-handed operation
– uses available materials
– distance fighting

Technical implementation:
– sawed-off shotgun
– uses right-hand-mounted chainsaw to saw off shotgun (story dependency or taking advantage of existing features?)
– convenient back holster

Bonus feature/discovered value:
– clever shorthand terminology: “Boomstick”

By now, the distinction between testable user story acceptance criteria focused on user value and the resulting technical implementation should be painfully clear. Groovy?

Tonight’s episode is brought to you by: the beauty of claymation, the number 2, and the words Klaatu… verata… n… Necktie. Nectar. Nickel. Noodle.

Image source

Rhythm section

03 Wednesday Apr 2013

Posted by in Acceptance Criteria, Approaches, Experiences, Experiments, User Stories

≈ Leave a Comment

camarolf-zydeco_tie

When I was a little girl, my mother took me to New Orleans. I was enchanted with the city and my experience there, not the least of which was experimenting with Cajun dancing and learning to play the washboard. As the New Radicals say, when “you’ve got the music in you / don’t let go,” so I suppose it was only natural that I decided to try becoming a percussionist in high school. Although I had the muscle memory for patterns involving 4 mallets and a foot pedal that garnered me vibraphone solos, I never learned to read music or march on the football field properly. In the Christmas show, our sleigh ride had a lame horse because I got out of sync and didn’t know how to recover, being an inexperienced musician.

Undeterred, I was always excited by the idea of playing the “toys” or strange percussion instruments that lurked in the back of the band classroom gathering dust. Sure, I’d tried playing a güiro, bar chimes, and maracas in elementary school music class, but the vibraslap, cabasa, and flexatone were new to me. Regrettably, most high school football game pep songs don’t call for that sort of thing, though indoor drumline competition allowed us a brief glimpse of the promised land in the form of tubular bells.

In recent years, my musical performances have been primarily vocal, though Michael Bolton can vouch for the my lack of skill with the bodhrán. (For the record, he rocks out on the mandolin.) And while I’ll never feel the rhythm of testing quite like Pete Walen, I keep my options open to try new instruments and approaches.

Telling compelling stories

One of the dozen books I’m currently reading is Edward de Bono’s Lateral Thinking. He mentions many useful ways to train yourself to become creative. I was thinking about these methods when considering the relationship between a user story’s acceptance criteria and the implementation that satisfies that need. In my daydreams, I am considering who to recruit for my next musical endeavor.

For every one with dollar signs in his eyes
There must be hundreds that look at you as if you’re some kind of
Rhythm section want ad
No others need apply to the rhythm section want ad
And here’s the reason why
– Rhythm Section Want Ad, They Might Be Giants

I immediately start down the list of musicians I know and don’t have a handy drummer to call. Then, I realize wanting to recruit a drummer is really just an attempt to satisfy my need for rhythm – and as I’ve seen with so many other performers there are so many more ways to accomplish that goal. If I’d phrased my requirement thus “As a person wanting to create a musical act, I want a drummer so that my song has rhythm,” I would have missed out on so many useful possibilities that occur to me when I challenge the assumptions in my own formulation of the problem and reject the dominant idea of a drum kit in favor of the crucial factor of rhythm.

By delaying my judgment, I open up the opportunity to brainstorm and generate alternatives to the cliché 90s rock band pattern that jumps out at me. So the key to my dilemma seems to be figuring out the right acceptance criteria (or user goals) that will tell me when I’m satisfied and then chatting up several of my musician friends who can propose diverse solutions to my problem (e.g. a sampler could give me all of the above).

I might even take some cues from established bands I’ve had the remarkable experience of seeing live and in concert who made alternative choices for their rhythm section, feeding the wannabe percussion geek in me. OK Go performed a gorgeous rendition of their song “What To Do” using handbells during a show here in Atlanta. During a visit to a friend, I saw Tilly and the Wall, a band that routinely performs with a tap dancer on a box providing some fascinating beats for their music.

While I might pull out a slide whistle to jam with my kids or spin a ratchet on New Year’s Eve, I’ll never be a hippie with a djembe. (Who knows? Perhaps I can find someone to teach me how to play a few beats at the DragonCon drum circle or the Georgia Renaissance Festival.) At least I know there are many more possible solutions for my future projects. And though I’m still holding out hope for that next ridiculous musical number, you won’t see me on Song Fight! any time soon… that is, unless a Zydeco Tie shows up magically on my doorstep.

Image source