Category Archives: product owner

A High Bar for Product Culture

My daughter is in the phase where she’s always asking me “why?”, so she asks me, “Why do you go to work?” …and I hate how a toddler has given me so much pause… because I don’t like my answer.

Here’s a window into an internal struggle:

Do you work for a company with an inspiring vision? Why the heck not? And why do you choose to spend your days contributing to a group that’s not improving humanity?

And now, here’s my struggle as I iterate on my Agility:

Why continue to focus on how things are being built & done when what we are building & doing is not improving humanity?

What do I tell my 2-year-old daughter? Continue reading

Mental Decluttering by Not Giving A

In the TED Talk “The Magic of Not Giving a F***“, Sarah Knight’s approach to minimalism is very… practical. And colourfully stated!

She covers her ‘notsorry’ method, which guards your time and treasure without you feeling like a… jerk. She ends her talk thus:

But mental decluttering: learning how to say ‘no’, set boundaries, and give fewer, better fucks? That lasts forever.

So decide what you don’t give a fuck about (know your ‘fuck budget’). Then don’t give a fuck about those things (honestly & politely). 12.5-minute video embedded below to better get this message. Enjoy!

Oh, and yeah, she audibly drops the F-bomb. A lot. But otherwise, it’s SFW!

Pain Is Just Information

I took a systems physiology class in college one summer, and on the very first day, the professor said, “If there’s one thing you remember from this class, it’s that ‘Pain is just information’.” Pain let’s you know something is up. Or down. Or out of place. Or stuck in place. Or generally amister amiss.

(This blog post is about a conversation from work. I’ll try not to make these boring and solely technical, but if you decide to give up on reading this because you’re emotionally distraught over Scotland not being its own country, remember: Pain is just information.)

Now that I’m a ScrumMaster by day (your local superhero by night), I get to talk through sticking points that my team members have with parts of the process, and the point that was sticking this time involved the Sprint backlog.

(I can’t believe it… to be your own country… you get to stay up as late as you want, eat haggis whenever you want, drink scotch whenever you want…)

During the Sprint, something may come up that we as a team end up working on, with the Product Owner’s blessing, that wasn’t planned for in the Sprint Planning meeting. The question is: If we can add things to the Sprint mid-Sprint, why can’t we remove the things we now know we won’t get done mid-Sprint?

(…skinny dip with my sheep in whatever loch I want…)

Seems like a decent enough question: by accepting sudden stories, you’ve already blown out the original plan, so why not update the plan based on new information? Since the Spring backlog is what the team committed to doing at Sprint Planning, it’s easy to understand why the team doesn’t want to see this thing they know won’t get done: it’s embarrassing, or it induces anger, or it elicits some kind of negative emotion (or else the team wouldn’t be asking to get rid of it), some kind of pain.

(…wear kilts as short as I want…)

The way I sell this is via acknowledging this ‘pain’ as not necessarily bad, but useful: at the end of the Sprint, the stories that do not get done represent a quantifiable adjustment to consider during the next Sprint Planning session. If no ‘outside’ stories were brought in mid-Sprint, then the undone stories represent the team planning to do more than they could pull off. If the story points associated with the dragged-in ‘outside’ stories were the same number of story points associated with the undone stories, then the undone stories were neatly ‘displaced’ by the sudden stories and the team did a spot on job of estimating how much work it could pull off.

(Did you hear about the Scottish cross-dresser? He wore pants.)

Sure, it feels icky to leave things undone, especially when you said you’d do ‘em, but if it’s because the Product Owner asked you to do something else, then heck, it’s totally not your ‘fault’ – the person in charge of prioritizing work… reprioritized work! And this was the particular scenario of the sticking point – there was pain, and it was reframed as information.

My systems physiology professor would be proud. If I only remembered his name… this sucks, I really liked that guy… man, this is embarrassing…

(Pain is just information.)

Oh shut up.

Home Is Where The Results Don’t Matter

Elizabeth Gilbert wrote “Eat, Pray, Love”, which became a bestseller. In a TED Talk she gave recently, she talks through how she struggled with the task of writing again, post-success, by looking back at how she kept writing post-failure. She called it “going home”.

And you have to understand that for me, going home did not mean returning to my family’s farm. For me, going home meant returning to the work of writing because writing was my home, because I loved writing more than I hated failing at writing, which is to say that I loved writing more than I loved my own ego, which is ultimately to say that I loved writing more than I loved myself. And that’s how I pushed through it.

your home is that thing to which you can dedicate your energies with such singular devotion that the ultimate results become inconsequential.

I think that’s beautiful, from the personal development Product Owner perspective.

What is your home?

Suddenly Deserve A Cupcake

My roommate, sophomore year in college, had a few phrases. My favourites were the euphemism of “intellectual clutter”, and the toothily grinned “treat yourself“.

(He also had a classy way of explaining vectors that involved demonstrating the resultant vector with a directional bobbing of his head between outstretched arms, his longer hair waving behind him like the circular ripples spawned when skipping stones at a steamy summer soiree. (My explanation of vectors is less classy and more… phallic. (That’s because vectors have both magnitude and direction. (Now you can’t unlearn that. (You’re welcome.)))))

This blog post is a continuation of the last, where I talked about leaving room in your Sprint for both the planned and unplanned, allowing yourself to be both proactive and reactive, where stories are thus either strategic or tactical. I can’t help but picture a yin-yang symbol at this point, so the Taoist in me is high-fiving me (from within) (odd… deep… deeply odd?) over my incorporation of balance into Sprint Planning. So let’s address value and effort, specifically for these ‘tactical’ stories that suddenly arise from time to time, by stepping through the Product Owner’s point of view.

The Product Owner is in charge of the vision of the product. For my ScrumOfOne, I view myself as a package of products (Merrill the musician, Merrill the financial responsible, Merrill the home dweller, etc.), each with its own vision. From any particular vision, there are epics, which are just large stories, which are broken down so that they are small enough to be taken into a Sprint, but within the context of its product backlog, a story has both value and effort. Value is indicated by its priority in the backlog. Effort is indicated by an assigned number of points.

All those items in those lists (stories in Product Backlogs) stem from a vision by the Product Owner.

So whether the Product Owner is telling the team to keep implementing stories from the Sprint Backlog (the planned), or to address issues that have suddenly arisen that can’t wait for the next Sprint (the unplanned), the direction is given based on what will get us closer to the Product Owner’s vision. Using this motivation, we will generally work on the thing with the next highest priority (subject to other Scrum principles like reducing work in progress to reduce waste and completing the Sprint Backlog to increase morale and allowing team self-management). Thus, if an unplanned task is suddenly a story with value, then like any other story towards a product vision, it should get points assigned for effort.

Is this cheating?

All I have to do is say that what I’m doing is good for me (something towards a product vision), and I suddenly deserve a cupcake (give myself points for the ScrumOfOne Sprint Backlog).

It sure feels like cheating, especially since it seems almost too easy! If I take my lady out on a date, I get points for a story completed that would have been from the ‘Be a good partner’ product backlog. If I have a friend visit, I get points for a story completed that would have been from the ‘Be a good friend’ and ‘Have a welcoming home’ product backlogs. If I get inspired to work on a project, I get points for a story completed that would have been from the… product backlog associated with that project.

In the corporate realm, sudden stories are taken in and worked on by the team, so you can bet your socks there are points associated with that effort!

Taking this to the extreme, you could be in extreme-reactionary mode, only doing things that come up. In the software realm, this is like only making bug fix releases and never building new features. In the ScrumOfOne realm, this is like only reacting to life and never taking initiative.

The second half of the Interrupt Pattern addresses this by programming an automatic abort of the Sprint if the buffer for unplanned activities overflows. So if the buffer for tactical stories is 15 points per Sprint, and the green light is given for a story that would mean we would complete 16 points or more of stories that were not from the Sprint Backlog, the Sprint pre-maturely ends and there is another re-planning. This drastic measure sheds light on the evident misalignment between planned priorities (Sprint Backlog) and actual priorities (embracing all interruptions).

So (…I tell myself…), if something comes up that is technically a distraction from the Sprint Backlog yet not a total mess (intellectual clutter), then feel OK taking it. Just remember to give yourself points afterwards (treat yourself).