My Agile Life: Failure

(This column is posted at, and Steve’s Tumblr)

I’m talking my “Agile Life” experiment where I use the Agile techniques in Scrum in my everyday life.  Well, it doesn’t always work, so let’s talk failure – specifically something that went bad this Sprint of May.

As you know one of my goals for the May Sprint was to plot a new novel and write chapter 1. That has partially failed – which is a great time to examine what I did wrong and talk failure.

Agile methods are all about learning as opposed to shame.  We all make mistakes, we all have discoveries of what we didn’t know, so the goal is to learn and adapt.

So first, let’s see what happened:

  • I was going to start a new novel, “A Bridge To The Quiet Planet,” an SF/Fantasy mix.
  • I was going to use a lot of the techniques I’d used before to write it – heavy setting detail, iterative plotting. Just on a larger scale.
  • I found things not feeling “right.” The plot was stale, parts came and went, I didn’t feel I had a grasp on the story – I had about 60% of it but something felt off.
  • After analysis I realized I didn’t have a good a grasp as I thought, it wasn’t quite “alive.” There were good parts – there were *great* parts. But it felt half-made.

So now the questions come in – “Why.”

There’s a great technique called “The Five Whys” that I learned – basically to solve a problem, ask why – and when you get an answer, ask why again. Soon you’ll get to the cause, part of the cause, or one of the causes.

  • WHY did it feel wrong? Because it was. It was patchwork.
  • WHY did it feel patchwork? Because some parts were far more fleshed-out than others and they conflicted due to that.
  • WHY are they half fleshed-out? Because my designing was erratic.
  • WHY was my designing erratic? Because I dived in and didn’t think of what I needed to do as a specific set of tasks.
  • WHY did I do that? Because I didn’t think I’d need it, I’d just dive in as I’ve done this before.

I came to realize I got a bit arrogant. I’ve written and built worlds for 40 years. I’ve published books. I should be able to dive into this right because I’ve done so many similar things?

Yep, I should – if I had thought ahead. But I didn’t think about what was needed, didn’t look at my techniques, didn’t break down the work. If this had been a programming project, it’d be the Product Owner and an Engineer saying “hey, we know how to do this easy, so let’s just block out some time” without the Scrum Master saying “why do you think this doesn’t need the usual level of analysis?”

What I should have done is use all my techniques and experience to design a better plan – how long it’d take for this tasks, what tasks were needed, and so on.  It would have made me think, made me more aware of the work needed, and how that work tied together.

Lesson learned – in writing, like anything else, a good work breakdown is needed.  Just because you might be able to do it “from the gut” is no reason not to think it over – especially when you’re getting back in the swing of things.  Had this not been a novel but a shorter work I might not have caught this mistake.

Now of course after finding this the goal is to get back on track. How am I doing that?

  1. I will focus this month on plotting – any time meant for Chapter 1 now moves to plotting.  That helps me get a timeframe.  It’s still adding work to my sprint, so I may move out other plans – since getting this done is important, and spreading it out too much may mean it loses coherence.
  2. Writing is moving out by one month at least – maybe two.  But I’ll try to do Chapter One next month and then slowly ramp up.
  3. To plot the book I am breaking it down into tasks required to get a full plot outline that I can write from.  It’s really more of a product design process or a research task.  I may write up more on that depending how it goes.

The story quality is already looking much better, and I learned something about my own creativity. Also the story may have a slightly off kilter Technomancer riding a motorcycle on top of a moving train, so there’s that.

A good lesson on many grounds.

– Steve

Steve’s Update 5/21/2017

(This column is posted at,, and Steve’s Tumblr)

It’s my weekly Scrum style standup for the audience.

Well bluntly this week also was nuts, with assorted work events, a friend having health concerns (resolved) and of course occasional allergies.  It’s not been the greatest week – but Agile method are about adapting.  So where are we?

So what have I done the last week?

  • Way With Worlds Minibook #5: Still going good and on schedule – I might even get a bit ahead of the game.
  • Seventh Sanctum Spotlight: That’s on hold.  This is due to the interruptions I’ve been having from allergies to events, and now convention time might cut into the results for me and other people.  So I’ll do it in June if it seems viable.
  • Professional: Attended that professional event – they’re running out of space so I found my apartment complex can host them!  A great way to network and meet people.
  • Social: Girlfriend’s birthday and book club went well.
  • “A Bridge To The Quiet Planet:” The latest plot outlines and character arcs are plotted.  Looks good again, and I think the book is taking on a more personal tone; for instance, there’s two minor characters (one extremely minor as in he’s in one scene) that by exploring I really did a  lot with the story.  This is a good lesson from the late Sir Terry Pratchett – you tell a lot more by having it personal, even if that person is gone after a scene.
  • Newsletter: The newsletter is out.  Which you probably saw.

What am I going to do this week:

  • Way With Worlds Minibook #5:  More writing.  Let’s just assume that’s the norm (and book #6 is next).  I’m thinking these books are best written in one or two big lumps not spread out.
  • Social: Fanime is going to consume a lot of time this week, as will events there.  I’ll be preparing presentations.
  • Speaking: I’m speaking twice at Fanime.
  • Cosplay: I’ll be Doctor Oobleck from RWBY at least one day.
  • Her Eternal Moonlight: A sale is coming, so pay attention . . .
  • “A Bridge To The Quiet Planet:” Next step is fleshing out the plot so it’s ready to be scene-for-scene outlined, as well as some character details.e

Challenges and blockers:

  • The Allergies are better, but I’m keeping an eye on them.  These were bad and hit a lot of people hard.

– Steve

Steve’s Agile Life: Work Complete

(This column is posted at, and Steve’s Tumblr)

So more on my “Agile Life” experiment where I use the Agile techniques in Scrum for a more productive, less-stressful life.  This is all about getting things done – so let’s talk about something we don’t often think of, limiting how much we complete in a day or a time period.

Remember when I talked about WIP, work in progress? That’s measuring “what’s not yet done,” and reducing it usually helps productivity and reveals problems.  But I found something related you want to pay attention to.

How much work gets completed in a day and over time.

I began noticing sometimes I’d deliver regular amounts of work, sometimes huge lumps. I came to realize that monitoring how much you get done in a time period – often a day – helps you improve your agility and your work.

Here’s what it can reveal:


It Can Reveal Overload

I’m going Agile and it means I’m getting more done.  That makes sense; I’m clear on what to do and what’s next, I can adapt to change, and because of all this I feel less pressure.  Yet, at times, I’m feeling kind of stressed despite improvements.

I realize now that this is because I kept looking for the next thing to do.  The productivity had become habitual and addictive, and I kept trying to move more to “done” – bringing more stress back to a process that’s supposed to reduce it.

This can be worse if you have well-defined stories and tasks. You can blaze through them relatively easily. You can get them to “done” pretty quick. I had a day “off” where I got a lot of work done as I had it broken down well – and then realized “hey, I am tired.” That spike in my cumulative flow was a reminder to go play some Overwatch.

It Can Reveal Bottlenecks

Those sudden droughts and onslaughts of completed work can reveal bottlenecks in your work and your plans.  This is usually heralded by a block of Work In Progress, but isn’t always.

Let’s say you’ve had to write three articles for three websites, sending them each out to editors, each at a different time. You’re getting work done while you wait, maybe keeping your Work In Progress from getting too high – then bang, all the articles come back at once.  Turns out they’re all great, you just have to sign off, but that’s stressful.  It shows your editors may be a bottleneck and you need consistent response time.

Also that sudden onslaught of “done” can be disruptive and jarring – context switching.

It Can Reveal Poor Breakdown

You’re working on all sorts of tasks, from painting a table to writing a book, but it seems they get done in huge lumps.  This might be a sign of poor breakdown – you’re delivering enormous “chunks” of work as you’ve got it set up to be worked on in enormous chunks.  Maybe your stories can be broken down into smaller pieces of value to do.

This can happen in “Agile Life” pretty easy as we may not think of breaking down tasks we’re used to – or lump similar ones into one pile.

It Can Reveal Forgotten Work

This happened to me a great deal in my first “Month Sprint” of April 2017. I noticed some of my erratic delivery and then, when asking myself what I did that day, realizing I’d done a lot of tasks that probably should have been in my backlog. If you see erratic delivery of work, it may mean you should be capturing more work.

This was a real revelation to me – because once I started capturing this work (a mix of social events, obligations, and my cooking schedule), my stress dropped. I was more aware of my goals and time commitment and could plan better and be more agile.


So beyond workload and work in progress, keep an eye on how much is getting “done” each day. It may reveal some problems in your plans and give you new ways to improve.

This recalls The 8th Agile Principle the value of a good, sustainable, pace of work.

– Steve

Steve’s Agile Life: Work In Progress

(This column is posted at, and Steve’s Tumblr)

Here’s the latest on my “Agile Life” experiment (where I use the Agile techniques in  Scrum).  Let’s talk Work In Progress or WIP, something my mentor wanted me to learn more about, and something that inspired my “Agile Life” experiment.

WIP is Work In Progress, a measure of how much is being worked on but is not done. It’s core to the Agile technique of Kanban and the measurement has been incorporated into other practices. WIP is “on it but not done with it” – from waiting on a test for finished software to just note done.

Why is it important? Because in general too much WIP (some would argue any more than one story) is a sign of bad things or can be bad things.  To much WIP might mean:

  • People are multitasking a lot.  Too much being done at once, nothing finished, lots of context shifting.
  • Too many blockers.  A lot is just holding people up.
  • Bad work.  Too much is held up in testing and fixing.
  • Testing problems. Maybe stuff is happening too fast and it cant be tested as fast as it’s getting done, or the testing team has problems.
  • Poor story and task design. The work as broken down is hard to finish or isn’t what people thought it was.

Note the first issue – Multitasking. Even if you’re not blocked by anything else, starting but not finishing things distracts you. You have to context shift. You have to keep track of many things. WIP’s problem can sometimes be its mere existence.

Very quickly as I worked to get more Scrum-like in life, I could see how easy it was to have too much WIP. This was especially bad with domestic chores, things I could “do any time” or “complete whenever.” For my first sprint, it certainly shaped up my housekeeping.

This also made me aware of the issue of tracking completion of Tasks versus Stories. Stories may deliver value so you want to get them out – but individual tasks can also get stuck in never-being done. Tracking those specific “in progress” tasks can be helpful. Makes me wonder if a cumulative flow of both Stories AND tasks would help me or other teams – after all if you’ve got 5 stories not complete due to 5 different tasks or one story not complete due to 5 different tasks, that tells you something.

Some Agile practitioners and practices limit Work In Progress (and people fight over this). The idea is that there’s a limit for a person, team, group, etc. on how much can be up in the air. Past a certain point, it’s either finish it, unblock it, or go do something else not in the Backlog until the stars align. This limits multitasking.

Frankly, I can see why people do it. One Agile Coach I know said in a class that a team at its WIP limit should do nothing until stuff gets done, even if other people spend time to go to training or something. Yes, I watched a highly experienced expert outright state – with conviction – that if a team has too much WIP and one guy has nothing to do, he ought to go read a book instead of start something else. His time would be better spent not complicating everyone’s lives by starting something else.

My guess is you can sympathize.

What do I consider ideal WIP? I’d say for an individual 2 stories and 2 tasks at most, and I’m starting to see why people often make it one story, at least in business.

A final note on WIP. Having lots of small stories you can bang out easy may sound great – but may also tempt you to do them when there’s a big pile of WIP. Even if you can finish something quickly, maybe you ought to finish something from that big pile first.

(By the way, there’s no guarantee reduced WIP is going to have benefits, there’s other variables. But it’s a worthy goal. And yes, people fight over this.)

– Steve

Steve’s Update 5/14/2017

(This column is posted at,, and Steve’s Tumblr)

And it’s time for another  Scrum style standup!  What am I up to?

Well bluntly this week also was nuts, with assorted work events, a friend having health concerns (resolved) and of course occasional allergies.  It’s not been the greatest week – but Agile method are about adapting.  So where are we?

So what have I done the last week?

  • Way With Worlds Minibook #1: Back from the editor, looks good, she kicked butt.  I’ll probably go into it sometime in the near future – but I’m not scheduled to until next month.
  • Way With Worlds Minibook #5: Still writing, and on schedule here.  Not much more to say.
  • Seventh Sanctum Spotlight: This keeps just being interrupted, and I’ve not had that great a response.  I’m going to try and get back to it, but may just delay until next month.
  • Marketing: I’m trying Amazon Marketing Services ads and have a bunch set up.  I think they might be working but it’s hard to tell.  I have no direct sales but had a spike in sales anyway.  I also am placing flyers around town in various locations, but am not 100% sure what’s working and what isn’t.
  • Seventh Sanctum General: Figured what to do with the Tumblr and planned that out.  And yes, you’ll have to wait!
  • Professional: Yet another professional meetup which was great.
  • A Bridge To The Quiet Planet:” You’ll probably see an entire post about this, but I ended up having to stop plotting it – it wasn’t coming together well.  Short form was it was a mix of being rusty, of mis-applying techniques, and not breaking down the work.  I restarted plotting it and it’s coming along great once I applied a bit more planning to the whole affair.  You’ll probably see a post on it – but short form is that I won’t work on Chapter #1 until next month.

What am I going to do this week:

  • Way With Worlds Minibook #5:  Write more of course.
  • Professional: One professional event this week.
  • Social: My girlfriend’s birthday and a book club this week.
  • “A Bridge To The Quiet Planet:” I’ll be finishing up some plot outlining and going over character story arcs.
  • Newsletter: Get my newsletter out this week.
  • General: I’ll may do some fanime preparation

Challenges and blockers:

  • Continuing allergies and various interruptions have me a bit concerned.  I might strip down some plans.


This week taught me a lot about adapting.  I cancelled writing a chapter to have time to actually develop the book outline.  I was willing to cancel a marketing idea because, simply, I needed the proper “mood” to do it.  I also caught a few missing things and got on top of them fast.  It’s likely I overplanned this month a bit, but hey live and learn!

– Steve

Steve’s Agile Life: Writing Time

(This column is posted at, and Steve’s Tumblr)

As I write about my “Agile Life” experiment (where I use the Agile techniques in  Scrum) I hope to get others to think about time management.  Looks like my friend Serdar over at Genji press got himself a thinking about time management.

He gets into his own blogging, how he has to carve out time, and how his cadence for projects differs based on the kind of said projects.  It’s a great insight into what he as a blogger does – but also he talks about his way of blocking out work.

As a great deal of his work is writing, he blocks out a time to write each day, setting a minimum time.  If he’s not up for one thing, he’s up for another.  That’s a smart writing technique, and I wanted to note where something like this can fit into the Agile mindset.

  • First of all, he notes that he sets aside time to write, but doesn’t necessarily choose what he writes until he sits down.  This is a great idea on two counts – he has a block of time, and can make the call as to what’s needed at the time.
  • Secondly, if you use this technique, why not consider breaking your writing work down into hour increments and tasks?  That way if you set aside an hour, you can use it to measure progress on projects.  Also, great practice for work breakdowns.
  • Third, this gets you into the habit of practice.  With writing and certain other creative skills, many people respond well to regularity to both accomplish work and hone skills.  Why not make that Agile, with regular writing, broken down so you can slot it into your writing time?
  • Fourth, this removes roadblocks, which is a big part of why we use Agile techniques (as I heard it put once, the prime focus of any Agile method is to find what’s blocking you).  By having this general time you can go around other writing blockages – but by having a set time to write you keep up the regular work you need.

What’s funny for me is I’ve tried both techniques and tend to lean towards not writing each day.  I tend to like task-based writing, to accomplish “x” goal, be it 30 minutes or 2 hours of writing.  But it’s all about finding what works for you.

(Then there’s people asking if they need a definition of “Ready.  Let’s not get into that.)

– Steve

Steve’s Agile Life: Done

(This column is posted at, and Steve’s Tumblr)

If you’re new to my whole “Agile Life” thing, this is me using Agile (specifically Scrum) to make my life more productive and less stressful.  Let’s talk about a big barrier to success – “Done.”

The latest lesson I want to share is the challenge of figuring out what “Done” is. Yes, trust me, people ask this.

When are you “done” with a task? With a story? With a book? “Done” is important to organizing since that’s when somehting is basically able to go out the door. “Done” is especially challenging if you have radically different work to do, and moreso when doing “personal” Scrum – because the definition of a done LinkedIn profile update and “done” for cleaning the refrigerator are kind of different.

“Done” plagues professional managers and Scrum Masters as well as people in less anal-retentive professions. I have sat in meetings, with grown adults, debating the meaning of “done” for a half hour.

I’ve also debated the exact meanings of the colors red, yellow, and green. I am not proud.

So you need to define “Done” for you and your work. Hopefully it lines up with some other people’s ideas of “Done,” but as this is your life you may have some unique challenges.

Here’s some I had – and how I resolved them:

  • Writing a book consisting of 50 questions. Well I know what the “done” is for the Book, but how do I organize doing these questions? So I decided to write questions in 5-question blocks. “Done” would be five questions ready for the editor. Incorporating edits would be a separate set of tasks.
  • Cleaning a closet meant ‘done’ wasn’t what I thought. Sure having things repacked is one thing, but disposing of the junk was another. As I had some ancient electronics I found disposal wasn’t so easy, so I got it organized in a box. I considered the closet “done” but created a new “story” to dispose of these things – if they were invasive, then it wouldn’t be done.  Plus a good lesson for next time.
  • Designing marketing flyers – This is a bit challenging. First I have to design the flyer, then print it. I made both of these separate tasks, but decided after some thought that “done” would be completion. The service was reliable enough and the design templated enough that if everything was a botch, I’d “re-open” the tasks and start over.

Done is not just important for completion, it’s when you get feedback. My cleaned closet was “Done” but the fact I had to create a separate disposal story was a reminder I hadn’t thought “Done” out too well.

Oh and remember if you have any kind of validation, like software testing or your Church approving your flyer, then you’re not necessarily “done” – it’s in testing. Surprise! You may be finished but not “Done.”

Or you may be arguing about what “done” is.

(Then there’s people asking if they need a definition of “Ready.  Let’s not get into that.)

– Steve

Steve’s Agile Life: Size Affects Pursuit Of Value

(This column is posted at, and Steve’s Tumblr)

Let’s talk Sprints and organization. If you’re new to my whole “Agile Life” thing, this is me using Agile (specifically Scrum) to make my life more productive and less stressful. Sprints are periods in Scrum used to choose – and do – work. It’s not linear planning, more “I can get X done in Y period.”

So I’m doing Scrum for my life, and my sprint is a month, not the traditional two weeks. I do this because my life has a monthly cadence, with monthly meetings, events, and the like. This also means I focus on value differently than if, say, I used two week sprints or the even more (insanely) daring one week sprint.

I have a larger timeframe, so I focus on more kinds of work (stories that deliver value) because I both can do more and have more to do. Thus where a two-week sprint might have me focusing on a generator, a monthly sprint may bring in more projects and work.

Because of my sprint size, I focus on value differently. I deliver multiple, unrelated kinds of value – where a smaller sprint may mean I focus on fewer kinds of value, and those are probably related. I’ve wondered if this dilutes my ability to focus, but also see some advantages.

Here’s an example:

  • In the first two weeks of every month I have three professional meetups – maybe four. These meetups each take up an evening.
  • If I have a monthly cadence then these big blocks aren’t as big a deal as I can fit tasks around them or just do some later. I have adaptability, but work might be diluted.
  • If I have a two-week sprint, then I have to think more of what to accomplish in that time, working with those “block.” of time. I’ve got a bit of a tighter backlog, but the focus is on specific value. For instance maybe I’d make these two weeks even more “business” and do studying, etc.

So smaller sprints means a narrower focus on value – and an opportunity to focus. Why not, I wonder, go by two-week sprints, and these “business blocks” could be enhanced if I also used that time to do studying for certifications, etc. However . . .

. .. this is also my life. That has a few complications:

  • Some work is very hard to “block” like writing. That’s intellectually exhausting, and though I’d like to try, I’m not sure I’m going to, say, write an entire book in a two week block.
  • This big picture lets me adapt easier because there’s more room to shift around. Because of the monthly cadence, I tend to “step on my own toes” less.
  • My “life” commitments are a bit more variable than work. When’s the last time your boss suddenly visited and slept at your place?  OK, don’t answer that.

Your life may be different, so you’ll have to find the sprint cadence that works for you. However, you might be surprised.

If you’re a Scrum Master or Coach, these “life Scrum” and “life Agile” experiences are valuable to develop empathy. By using these techniques in your life, you literally live them and live the roles of all members – Scrum Master, Team Member, Product Owner. Because of that, these experiences are burned into your brain in a visceral manner – next time your team debates value and sprint size, you’ll remember what it was like.

– Steve

Steve’s Update 5/7/2017

(This column is posted at,, and Steve’s Tumblr)

And it’s time for another  Scrum style standup!  OK it’s weekly, and I prefer them daily but that’s a bit much.

First a note – I had a nasty allergy attack around Thursday which held a few things up.  I’m overall on time/ahead of my plans but it was annoying

So what have I done the last week?

  • Way With Worlds Minibook #1: Editor had a bit of a delay, so I expect to get things in a few days.
  • Way With Worlds Minibook #5: Got actually 10 questions written.  I find more and more these are best written in large amounts.
  • Way With Worlds Marketing: The bookmarks came.  They are awesome.  Let me strongly recommend Club Flyers.
  • Seventh Sanctum Spotlight: I held off on this when some allergies hit.  I’ll probably start them off in a week or so.
  • Professional: Two professional meetups, they were awesome.  I really enjoy the “Agile Crowd” here in the valley.
  • Social: Bad movie event was great.  We saw “Mac And Me” which was hideous, but before that watched “Misfits” which was good.
  • A Bridge To The Silent Planet:” A bit harder than I expected.  It’s about 1/4 plotted with some outlines out to the end.  It’s becoming a bit more of a small novel – neither a doorstop nor a novella.  Which I realized is what I want.  However it’s a bit hard to shake the rust off so its’ slower than I wanted – and the allergies didn’t help.

What am I going to do this week:

  • Way With Worlds Minibook #5:  Write more of course.
  • Seventh Sanctum Spotlight: May or may not do this.
  • Professional: One professional event this week.
  • Social: Got a barbecue and otherwise will work on creative projects.
  • “A Bridge To The Silent Planet:” I plan to finish the plot outline this week.
  • General: Some basic chores and such.

Challenges and blockers:

  • The allergies hit hard.  I might delay a few things unless these clear up in the next day two.  Expect a possible “revised sprint.”

– Steve

Steve’s Agile Life

(This column is posted at, and Steve’s Tumblr)

You’re going to want to read this; yes it’s on time management, and yes it’s worth it.  I’m going to talk about management but in a non-boring way.

Remember how I moved to Agile techniques and started those weekly reports?  Here’s what happened.

In March I felt my time management could be better; I felt overworked, fell into multitasking, and knew I could do more.  Sound familiar?

I had organized myself by a mix of Getting Things Done (GTG) and Scrum/Agile, but it was casual.  Since I’m a a pro Project Manager and Scrum Master moving towards coaching and process improvement, I know a lot of techniques and processes and coaching tools.  So I coached myself towards more productivity and less stress.

It makes sense; my life is more like a business with my books, and so on.  So what I did was use the Agile practice of Scrum, combined with some GTG (which if you want to really argue, is kind of Kanban, but let’s hold off on that).

To help, here’s a quick refresher about Agile/Scrum – and trust me, you’ll also want to read this.

Agile is a management philosophy that evolved from software development.  To sum it up it’s “A focus on delivering results regularly by working directly with others and responding to change.”  Here’s the 4 parts of the manifesto and 12 principles that will give you an idea.  You really want to read this stuff.

Agile is a MINDSET with a focus on delivery and adaption.  It’s important to keep this in mind – literally.

Scrum is the most well-known Agile Method.  Take a priority-ranked backlog of what you want to do, figure out how much stuff on the top you can do in a given timeframe (called a sprint, usually 2 weeks).  Do the stuff, deliver, evaluate how you did, then do it all again.  The goal is to get something done and learn – that something could be bad or not ready for prime-time, but it’s done.

Make sense?  As I like to put it (sarcastically) if you deliver value often and re-evaluate, you get benefits fast, but also there’s only so much you can screw up in short bursts.

So time to adopt an Agile mindset, and Scrum was the best method to do it.  Here’s what I did.

  1. I made an Agile Backlog (from my GTG Incubator).  This is basically a list of things I want to do ranked in order of value.  I re-evaluate this regularly – this is not a random repository of ideas (I have separate documents for that).
  2. I have a Project List (a GTG artifact) of active initiatives.  This is basically the top of the backlog for what I focus on, and have some plans or outlines.  I’m probably going to merge this into the Backlog.
  3. I have a flight plan (a separate artifact) that lists my general goals per quarter and month for up to two years.  I revise this as I change plans.  This is a quick way to look ahead and look for any schedule collisions. It’s not quite a roadmap, more a projection.
  4. I do monthly sprints, and the above help me decide what to do.  The Projects get priority, the Backlog feeds new projects or smaller initiatives.  The Flight plan lets me evaluate my goals and look for bottlenecks.  Yeah, this could be the classic 2 week sprint, but my life seems to have a monthly cadence.
  5. Work gets broken into stories that provide actual value, like a completed essay or a clean bathroom.  Learning to describe stories and figure value is part of the learning process, and an area of intense discussion in Scrum/Agile.  Short form is think of your target audience what they want and why – “As X I want Y so Z.”
  6. I break stories into distinct tasks used to get the story done.  A good rule is a task is something you can do in a day or less (and if you’re really good, 1-2 hours).  A story may be so distinct and so simple it has only one task – “As a gamer I want a Playstation so I can play Persona 5” doesn’t need any more breakdown unless you REALLY want to block out the drive there, the purchase, the drive back, etc.
  7. I estimate tasks in terms of person-hours so I can look at my workload.  There’s endless discussion in Agile and practices like Scrum on how to “size” tasks, but I find in the end hours always win because eventually whatever you do is going to affect, be measured in, or be communicated in time.

There.  I got a Sprint Backlog of work to do.  how did I use it?

  1. I review my backlog daily to see what I want to do.  I also do a weekly overview of my schedule, work, etc. to get an idea of what’s up.
  2. When I take a task I focus on getting it complete (ready to validate) if not done.  In a few cases complete is done: “Hey, the kitchen floor is no longer disgusting”
  3. If something is not immediately done, in that it continues or needs testing, I get it done in a short time.
  4. If things have to change – so be it.  I know what I’m adding and what I’m taking out.  A lack of change should be due to good foresight – resisting change isn’t inherently a virtue.
  5. I chart my tasks in the categories of Backlog (not started), In Progress, Testing (making sure it’s done), and Done (complete, finished, off my hands).  I do what’s called a Cumulative flow, charting it by task hours in the categories (more on that in the future).
  6. At the end of month do a retrospective- review how things went, decide what to improve.
  7. Plan the next sprint (month).
  8. I might keep my quarterly review (which is part of GTG and other techniques), but am honestly debating how necessary it is.  Probably good to keep it though as I’ve got a lot going on.

This worked great for April – a busy month, yet I got a lot done. It also lets me seriously crawl inside of Scrum and Agile because I’m doing the work, managing myself (Scrum Master), figuring the product (Product Owner), and more.

I’ll be sharing other findings in separate posts, but a few here:

  • You won’t see a lot of “do X by Y.” There’s some obviously, but in general I leave it open – because my daily and weekly reviews let me figure out the best time to do things.
  • I measured completion with Tasks not Stories – which I consider improper as stories deliver value. I did this originally because many of my “life” stories were one task, but it didn’t measure completion of my few multitask stories, which really did affect my time management and sense of completion.  I’m moving to stories next sprint.
  • I’m already keeping a “next sprint” list as I get ideas of what I want to do next; I realized I can easily apply lessons to the next month.  This is a good example of iterative improvement and time-saving – and “backlog polishing.”
  • I keep a “regular” tasks list I can now copy over from sprint to sprint as some tasks for my “Agile Life” keep repeating.
  • This may sound like a radical restructuring – it sort of was and wasn’t.  If you try something like this you don’t have to do it all at once, but add things iteratively, over time.  I’ve got more to add myself.
  • I’m going to be making changes to how I manage the backlog and projects.  To not overwhelm you with technique, I’ll probably post that later after I share some other insights.

Look for more posts on this – a lot more.

– Steve