Category: sprint backlog

Hello – Is It Me I’m Looking For?

I can see it in my eyes.
I can see it in my smile.
I’m all I’ve ever wanted.
And –

…if we check out the System page of this blog, we see how this whole ScrumOfOne set of practices I’ve forged actually increases my Inner Peace.

Man does that sound awesome – I want me some of that existential goodness.

Sometime before the home settling, the wedding, the move, the move prep, and the wedding prep, I stopped being fully engaged in applying Scrum principles to my personal development. I had been working off of a Scrum-Lite process where, yes, I had a backlog, but it was to keep track of the things to which I was largely reacting. While the days were focused on mostly logistical issues, and rightfully so, what was missing was personal growth, and the accompanying Inner Peace.

Now that things have calmed down, with the state of the home being that folks have been able to stay over without being warned to mind the bear traps duffle bags and to watch out for that tree box, I’ve returned to putting things in a number of personal backlogs, prioritizing them, and siphoning off a few into the current sprint. And just the process of doing all that has felt grrrrreat! The relief has come less from knowing where I am going and more that I am not missing anything. I can’t get all the things done now, but they’re not forgotten, and the most important stuff is getting addressed. Very Scrum. What’s that tingling in my toes? Oh yeah. Inner Peace.

So I’m back on the bandwagon, and man do I not want to fall off and lose my growing Inner Peace… or… get dysentery.

Want more transparency? Fine. I thought it would be enough to tell y’all that I’m wicked pumped to be back in the game, but you’re egging me one… I’ll publish my velocity and the Kaizen story so y’all can learn along with me. There. You’re welcome.

The more important bits of Kaizen will fall into an improved System page – I’ll update that section to reflect what has been practical and repeatable.

First piece of Kaizen (for Sprint 141, which is the number of paychecks I’ve received, with a biweekly schedule that conveniently aligns with the sprintly schedule): Actually read the Sprint Backlog each morning. It’s simple, but this is the piece of adaptation that is independent, negotiable, valuable, ‘estimatable’ (such a clumsy word), specific, and testable that gets Scrummin’ back into my daily routine. And Inner Peace. Let’s not forget that.

Let The Wookie Win

Have you ever completed something? Of course you have.

Do you know how good that feels? Of course you do.

So it’s no surprise that painting the last big room in your new apartment, followed by closing out your storage unit such that everything you and your new wife own is now under one roof, followed by capping off Netflix’s ‘House of Cards’ season all feels pretty freakin’ exhausting great! Everybody should get to feel this… more often!

So why don’t we?

At this point, I’m taken back to my Product Owner training, where (Scrum co-founder) Jeff Sutherland waxed poetic about… sports. So, with me please, imagine a sports team – your good ol’ neighbourhood generic sports team – it don’t matter what the sport is, just pick one – yes, any one, seriously – fine, curling – I picked curling for you – full-contact no-holds-barred curling.

Imagine that this team loses a match. Sucks, I know, but curling isn’t immune to losing. Think of what it’s like going into the next exciting match. Got it? Got that feeling? OK. Now imagine going into this next match, but having WON your previous bout. Got it? Got that feeling? Great – you’ve already visualized way more about curling than the average Canadian bear.

Gently slide curling aside for a moment, and apply these thought experiments to two completely different sporting and oxymoronic words: Scrum sprinting. By equating not finishing all the planned stories in a sprint to losing, and finishing all the planned stories in a sprint to winning, you get the feeling with which you go into the next sprint.

And it’s not just a feeling – there’s research to suggest that this kind of ‘failure’ prevents the team from improving, and that teams that finish early accelerate faster. Putting the ScrumOfOne hat back on, this means both not jam-packing your sprints with things to do, and preventing distractions from shifting your focus from getting things done.

Easier said than done? Well, I start with setting the bar lower, by setting myself up with fewer stories per sprint (the planned), and then leaving a buffer for things that come up (the unplanned). This is so common a tip in practicing Scrum that it is its own ‘pattern‘, where you can find more patterns here. These are ways to get started with Scrum and then get to Sutherland’s idyllic hyperproductive state. Interesting stuff, and it’s not too hard to see a ScrumOfOne corollary.

All The Things In Two Minutes

Allow me to apply the wisdom of one article – How to Stop Procrastinating by James Clear – to ScrumOfOne, specifically the building of a Product Backlog. James recommends using the power of the ‘2-Minute Rule’, which has two parts. He starts the article with a reassuring introduction:

Most of the tasks that you procrastinate on aren’t actually difficult to do — you have the talent and skills to accomplish them — you just avoid starting them for one reason or another.

Part 1 – If it takes less than two minutes, then do it now.

Think about the list of stuff on your to-do list / personal backlog… can some of them be banged out in a couple of minutes? For me, some of them actually can! Visualizing their realistic ability to be completed while an 800m sprint is taking place is motivating.

Part 2 – When you start a new habit, it should take less than two minutes to do.

Alright, how about things that take longer than a footrace? Well, much like a footrace, it starts with risking your own beheading as you try to win the heart of the fastest female mortal in all the land the first step. It starts with… starting.

So, back to your backlog… can you start some of those items in a couple of minutes? For me, these larger items seem more manageable knowing that I can get some momentum with a time-boxed amount of focus.

I like this exercise (“Can I do this, or at least get started, in two minutes?“) when thinking about the size of stories, as a factor for determining points (as an estimate of effort). If a story is too large by this measure, might it be too large to drag into a Sprint?

So there: now you only have to focus and really work for two minutes! Momentum carries you the rest of the way, and the things on your Sprint Backlog just got easier. All the things.

How Not To Forgive Myself

Two guys walk into a bar. (Ooh, a joke…) One guy says, “Hey man, good to see you again.” (Alright, so this next part will be the funny part…) The other guy says, “Hey man, I don’t entirely want to be here.” (…well that was hardly worth a chuckle)

That’s what I actually said to him! Was that rude? (Oh, it’s not a joke, Merrill’s the second guy.)

At my Scrum Product Owner training session over three months ago, I met a Product Owner, started talking about my application of Scrum to Personal Development, heard how he was into using Scrum for Professional Development, and then took the conversation back up a couple of days ago. (A man-date?)

So when I told my buddy that I didn’t want to be there (“I was being a wicked rude jerk-face”), it was in the context of how I see a necessary level of forgiveness from the Product Owner in ScrumOfOne. In ‘regular’ Scrum, this is analogous to the practice of building a buffer into Sprints: a reservation of a part of the velocity for things the team or Product Owner decides to get done that arrive mid-Sprint. (You mean you can’t stick to a plan for a full Sprint?)

It’s because you can never plan what opportunities may arise or what fires may suddenly need putting out – and definitely not for a full Sprint. (Oh.) Thus, I almost NEVER fully follow through with what I set up at my ScrumOfOne Sprint Planning meeting. (And what, you beat yourself up for this?)

And I feel bad (oh) because I see these remaining Sprint Backlog items at the end of two weeks, staring me in the face from the glowing rectangle that lives in my pocket. (‘Glowing rectangle’, that’s funny.) This is what I brought up with my buddy. (Did you mention how you talk to yourself in your own blog posts?)

By me grabbing a drink with him, I’m NOT doing something I had already set up for myself. The forgiveness comes in if I ultimately believe that the activity I DO do (tee-hee) is effectively a story that gets me closer to some vision for myself. By chatting up somebody in the thick of promoting Scrum at corporations, I knew I would learn a tonne (the metric ton, good choice) about the various adoptions of the framework, and I think we were able to devise some concrete next steps for getting professional development underway where he is.

(I get it: doing the man-date meant you didn’t do stuff on your Sprint Backlog, but in the larger picture, it’s all good.)

So now here is my struggle: I want to replace the notions of forgiveness and anxiety over not accomplishing carefully prioritized stories towards building the product(s) of me, with the notion of judgement-free doing.

Yes, I’m trying to weave the Taoist concept of Wei Wu Wei (effortless action), or at least a consequence of this idea, into ScrumOfOne.

Suggestions?

(Yeah, he needs all the help he can get!)

Kaizen Story

As I’ve worked with Scrum in a context that is not software development, I’ve come to define Scrum thus:

Scrum is a framework for getting stuff done that embraces change, while promoting transparency, inspection, and adaptation.

You get transparency from the Daily Stand-Up meeting (this is called the Scrum, too), and both the Sprint Burndown Chart and the Release Burndown Chart. Everybody starts the day on the same page, blockers are identified, and outside parties are privy to the progress during the Sprint and towards a release-worthy product; these are formats for easy sharing and digesting of Sprint-related information.

From all the data being laid out from the Burndown Charts, we can get inspection. The Sprint-end demonstration (part of the Review) also allows for a frequent check on the state of the software and acceptance of the stories done during the Sprint: inspection of the work. Inspection of the process is done during the Retrospective.

And the Retrospective is THE place where adaptation is determined. After inspecting the process, using methods I’ve mentioned in the previous two posts, we ideally get a somewhat prioritized list of stuff we either want to keep, stop, or start doing: a backlog of adaptation options.

Now, we pat ourselves on the back, go straight into Sprint Planning, and restart the Sprintly cycle.

And fail.

I mean, if we just come up with a list of ways we can get better, but don’t really do anything about it, then the Retrospective was a jolly ol’ waste of time. Does this sound like post-mortem meetings you’ve been a part of? Were they called ‘Lessons Learned’ meetings? See, I passionately dislike that term, ‘Lessons Learned’. You cannot say you’ve properly learned your lesson unless you repeat a situation and then exhibit ‘better’ behaviour, thus proving that you have indeed learned your lesson. Until then, you’re just talking about ‘how it all went’, an ‘Issues Encountered’ meeting, sharing what you’d do better next time.

The Retrospective is different.

At the top of the backlog of adaptation options, there must be an immediately actionable process improvement that can be implemented. How to ensure you do this? Make it a story for the upcoming Sprint: the Kaizen Story. Kaizen? Yeah, it’s Japanese:

Kaizen is a Japanese business philosophy of continuous improvement of working practices, personal efficiency, etc. Kaizen literally means ‘improvement’.

So, via Kaizen, we adapt. Via the Kaizen Story, a properly formed Sprint backlog item with points and acceptance criteria… and is independent, negotiable, valuable, ‘estimatable’, sized to fit, and testable… and is otherwise meeting a Definition of Ready for stories, the team is constantly working on improving the Scrum process, specifically using a measure uncovered and set by the team itself. (What’s that? At the back of the room… is that… is that the ‘self-management’ flag being waved? Why yes. Yes it is.)

I don’t have a clever way to end this post besides expressing how I think this idea is just so damn cool: Scrum becomes a framework for both getting stuff done and for improving how stuff gets done.

Genius.