Category: sprint backlog

On Point…s

You have something you want to do. You’re doing it for a reason (it has value, or benefit) and it doesn’t come free (it has cost, like time or money or focus). Generic enough of a start for a blog post? Good. Let’s talk Scrum.

You have a story. It has a benefit (business value) and a cost (effort). The backlog is a list of things to be done (stories), where this list is ordered (prioritized) by business value (fine, personal value since we’re in ScrumOfOne-land, or just value), with the highest / most important at the top. Each story has points associated with it, representing effort.

Business value is represented by backlog priority. Effort is represented by story points.

This is simple. This is Scrum101. And this is something I didn’t fully get until the Product Owner training last week. From this simple and clear concept, I am amending how I’ve been doing my ScrumOfOne.

More important stories are not ‘worth’ more points. How much a story is ‘worth’ is represented by its position in the backlog (be it the Sprint backlog or the Product backlog) and by this qualifier ONLY. Yes, the more valuable a story is, the more effort it might be, but not necessarily. For a recent example, I look at how I handled stories related to getting the Product Owner training.

I started with an ‘epic’ (just a large story): Become a Certified Scrum Product Owner. Then I broke it down to investigating the training options & timing, signing up & paying for it, getting reimbursement paperwork underway at work, and attending the classes. The epic, though important and thus close to the top of the backlog, is too large to fit into a Sprint, so it was broken down. Of those stories, ‘attending the classes’ was relatively the easiest (least effort): just show up! Of those stories, ‘investigating the training options & timing’ was relatively the hardest (most effort): spend time.

These stories, in retrospect, in and of themselves do not require a lot of effort, so they should not get a lot of points. Yes, working towards another Scrum-related certification helps me in better crafting this ScrumOfOne idea and improves my marketability, but this does not mean it gets lots of points. Instead, it gets a better/higher position in the backlog.

In the business world, coming up with a value per story means find the dollar value. In the world of personal development, coming up with a value per story is… harder. In both cases, this is one of the jobs of the Product Owner: prioritize the backlog, i.e., identify the value (thus, relative value) of each story.

With my example above, I would say this set of stories had high value and low effort. One would think these types of stories would be ones to do first – prefer to implement stories with the highest benefit to cost ratio. Or I could just look at the title of slide #52 of the slide deck from last week’s training:

Prioritization of Business Value / Effort Can Cut Cost and Time to Market by 50%

Filtering out the MBA-speak, this might look like:

Prefer to do the coolest stuff that’s not that hard to pull off.

And this starts with getting the idea behind ‘points’ straight.

Art of the Possible

In one of his Google Tech Talks, Jeff Sutherland, co-founder of Scrum, uses the term ‘Scrum-but’ to describe companies that incompletely implement the software development framework. When he consults, he’ll hear, “Yeah, we do Scrum, BUT…” and then some reason why they’re not a pure Scrum shop. In my head, they’re showing Sutherland around and at some point, flash-mob-style, folks congregate around the ping-pong table and sing it a la Annie:

It’s a Scrum-but life, for us,
It’s a Scrum-but life, for us,
Our velocity’s not – so – sweet,
But our process can’t – be – beat,
It’s a Scrum-but life!

And this is the reality of it. Here you are, introducing the new kid process on the block, leading the crew with a new philosophy as a ScrumMaster, or in ScrumOfOne land, at times competing with the existing processes or priorities of life. I like how Ken Schwaber, co-founder of Scrum, discusses it in his ‘Agile Project Management with Scrum‘ book:

…the ScrumMaster has to operate within the culture of the organization.

The ScrumMaster walks a fine line between the organization’s need to make changes as quickly as possible and its limited tolerance for change.

…sometimes these changes are culturally unacceptable and the ScrumMaster must acquiesce. Remember that Scrum is the art of the possible. A dead sheepdog is a useless sheepdog.

Back in ScrumOfOne land, the organization’s culture is… us. This can make it stressful, but it doesn’t have to be!

I used to hold my personal and formal 15-minute stand-up meeting at 5:31am. Past tense. My stories are not complex enough to be broken into tasks. I haven’t invested in any Sprint Burndown chart. I don’t have a formal demo for myself. I don’t always go through and clearly describe the acceptance criteria per story. I have tried each of these things, but none have stuck thus far.

So did I beat myself up for sucking at my own ScrumOfOne?

Yes.

I’d create stories to add more rigor to my personal development system, and then implement them. Slowly, through practice, I felt more and more in control. Not all processes would stick, though. And did I bet myself up for continuing to suck?

Yes.

At some point, I stopped feeling like a putz for seemingly setting myself up to fail. At some point, Schwaber’s words sank in with the deeper appreciation of that phrase: Art of the Possible. Via finding solutions that were good enough (better than perfect), and working with myself instead of against myself (tendencies, social pressures, bow tie affinity), I understood that this system is fully mine! I don’t have to be pure Scrummin’ if I am getting stuff done while promoting the principles of transparency, inspection, and adaptation.

So you start scrappy, but you’re getting stuff done, a la Jay-Z.

From The Front Lines: Task Ownership

This is a success story since becoming a tactical ScrumMaster at work. It’s nothing that directly relates to personal growth, yet the following practice can aid in not taking on too much during your Sprint, just as it is helping my team members work at a sustainable pace.

In theory, Agile teams are made up of generalists: coders, testers, requirements folks, release engineers, all these people can do the jobs of the others; they are, well, agile. This way, anybody can do any task associated with any story in the Sprint backlog. In Scrum, this is encouraged; assign your name to a task that you are doing, or about to do. Nobody assigns your name to a task without your permission, since this violates the principle of Scrum teams being self-managed.

In practice, folks aren’t as agile. For example, I test medical devices. (To younger folks, I say something along the lines of, “I break expensive equipment, and they give me money to do it.” To complete strangers at my favorite cafe, I lie.) You want me coding? Fine, but I’m rusty; it’s inefficient and will drag down team velocity unnecessarily. Thus, per story, coding tasks will most likely be done by one of the coders, testing tasks will most likely be done by one of the testers, etc.

Introductory passages out of the way, here was the pain point. Our team is doing better than expected regarding velocity, in part due to the high level of commitment to the team each member has, as per a recent survey, and as per my own Spidey-senses. This commitment was so high, that sometimes, a team member would dive into implementing a story, realize it was hairier than the number of Story-points reflected, and (not-so-) quietly trudge uphill to get it done in time for testers to play with it before the Sprint end. This meant longer hours, which is not a sustainable pace – bucking against another Scrum principle.

Each morning, we do that 15-minute stand-up meeting, taking turns saying what we did yesterday, what we plan on doing today, and if there is anything stopping us or slowing us down. Ah, transparency, right? How much more see-through could we get? Well, this meeting did not cover a simple comparison: remaining hours of tasks assigned to me vs. remaining hours in the Sprint.

I recommended that we tweak a Scrum principle of self-managed teams: Assign your name to every task you think you will most likely do. The benefits:

  • The tool we use for Scrumming (tracking tasks, stories, backlogs, etc.) shows a simple graph of remaining hours per person, so we can all use that to ensure nobody is overloaded from a pure numbers perspective.
  • Assigning a task to yourself is not an etching in stone, so we can all see who might need help completing their tasks: you can hand off your tasks.
  • We can all see who is wrapping up their tasks and thus has bandwidth to help somebody out in completing a story.
  • With testing tasks usually done towards the end of the sprint, we can all see roughly by when the coding tasks for a story should be done, thus acknowledging inter-dependencies.

I asked that we all do this, not so that management could see what everybody was up to, but so that we had opportunities to help each other out as we got stuff done, at a sustainable pace. This added level of transparency was adopted by the team and I think it’s been helpful. We’ll see at the next Retrospective.

How does this help you with your ScrumOfOne? If you have hours associated with stories in your Sprint backlog, just total them and compare that with the number of hours left in your Sprint that you think you can dedicated to stories.

Be realistic: do at sustainable pace.

Frustration

Once upon a time, I was frustrated.

This was, like, yesterday.

I just didn’t like how things were going, to the point where I got home, plopped myself on the couch, and sat there, staring at a candelabra that had way more color than the state of my soul. Things weren’t going my way.

Ha. Now that I’ve typed that, I realize that is a very accurate phrase to describe my mood all those day ago.

Things weren’t going my way.

Thus, I ruminated on this thought, chewing through the fat of gloomy cud, regurgitating thoughts that led to:

Oh, those dang things! It’s their bloody fault! They weren’t doing what I wanted them to do! Grrr!!!

Once I realized how I was thinking about these things, I bit my tongue; I chewed through my frustration. The insight was recognizing my passivity. The solution is being a ‘Man (/Woman) of Action’.

Granted, there is some solid good that comes from working through grief and not just sweeping undeniable emotions under the rug (you’ll just trip over them later). So once I did that, by sitting and doing nothing useful because I felt like the accomplished equivalent of a gastronomical intermediate by-product, I figured I should make a plan of action, and follow through, based on a set of values I find important – y’know, taking action.

Oh, that’s right. I already did that. I have one of those. It’s called my ScrumOfOne personal Sprint backlog, built off of my larger backlog(s) of things I want to do and be, prioritized by what I find important.

Stick with the plan. Tweak every couple of weeks. My plan.

Phew. That was a lot to go through since, like, yesterday.

That First Tiny Step

You have a dream. OK! Fine! You have a few dreams, but let’s pick just one. What’s it like? What are… the symptoms?

Hello, America. Do you suffer from something that is any or all of the following?

Well then, America, you have a dream!

Scrum is great for breaking down an epic-sized, daunting thing into a story-sized, conquerable thing, and then openly managing that. The ScrumMaster in me would sit you down, and after 5 seconds stand back up and walk with you to a whiteboard, since those are fun, then help you construct a Product Backlog based on your vision, prioritize that list, then draw a line in the sand on the whiteboard and bellow, “Behold, O America, for the next fortnight, sallyeth thee forth and kick ass,” while pointing to the stuff above that line.

Now, America, I do look forward to our date over Spanish lattes to bust through this in a fun-filled manner, sallyething thee forth ‘n’ all, but until then, ask yourself: What is that first tiny step towards my condition dream? What’ll get me that tiniest bit closer? What takes almost no time and no effort, yet dips my toe in the water?

This’ll of course depend on the disease dream. For me, that first tiny step was purchasing the following KORG Kaoss Pad 3.

Schuper Schweet, I know. How does this affect my dream?

  • It is still large – that’s how they tend to be.
  • It is not as far away, I just brought it closer.
  • It is clearer, since I have a tool with which to work.
  • It is still exciting – that’s how they tend to be.
  • It is less out of my league and more in my gym bag next to my desk in my apartment.
  • It is still possibly too awesome, and I’m getting a better handle of it, since this one piece fits in my hands.

Sallyeth thee forth and kick ass – take that first tiny step.