Steve’s Update 12/18/2017

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

It’s my weekly Scrum style standup for my audience, so what’s up?

So what have I done the last week?

  • “A Bridge To The Quiet Planet”: Edited out to Chapter 9.  The plan is to get the first run done before/around Christmas, then take a break.  I’m also working on the revised plot outline for the second run – which will take 2 months.
  • Way With Worlds Minibook #6: My editor keeps getting hammered, but hoped to have it early this week.
  • Blog: I queued up even more of my personal agile methods.  I may finish this before December.
  • Other Stuff: Got sick so things slowed down.  I also started a new generator and finished my Christmas stuff.

What am I going to do this week:

  • “A Bridge To The Quiet Planet:” Just more editing and more on the plot outline.  Fortunately I have the first fifth re-outlined – and it’s going to be not only more fun, but get into some crazier areas.
  • Way With Worlds Minibook #6: Really hope to get editing.
  • Other Stuff: Vacation starts soon, so I will relax – and prepare for Christmas!


  • This has been an odd month with many ups and down, illnesses, and more.  I may make some changes to plans once I slow down during the holiday.

– Steve

My Personal Agile: Work

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

Now let’s get on to the next step of my Personal Agile – doing actual work! You’ve got your Sprint Backlog, which is everything you plan to do this sprint (a month) so let’s go.

How Do I Start?

Every day I look at my Sprint Backlog and figure what I should do and want to do. Then I do it. In time you get into a rhythm where you unconsciously know what you want to get done – usually.

Yeah, that’s it. A daily review – maybe more than once a day – and doing stuff. Sounds simple? Of course it is – because you’ve thought this over and taken a manageable chunk of stuff to do. One of the great parts of Agile methods is that you get enough mindwork done up front and break stuff into manageable chunks that it’s easy to focus.

Well, What Do I Do First?

That’s pretty much up to you. In general, you should tackle highest priority work first and work your way down.

In practice, it’s often not as clear cut:

  • There are time constraints on when some things have to get done. You may not list cleaning that grungy guest room sink as your highest priority, but mom’s visiting.
  • Some work may need approval, materials, etc. Those art supplies you needed are late.
  • Some work you can’t stand doing for an extended time period. Maybe you start mowing the lawn this evening but finish tomorrow (but hey, maybe your mowing should be two tasks or even two separate stories).
  • When you start things you quickly realize your priorities are off. You really don’t need those new clothes.

Priority order is a good guide, but the only one.  Do what works.

Sticking With Things

To make sure you progress and stay focused, you want to stick with work.  Here’s a look at what I do:

  • If you take a task, make sure it’s one you can complete in one sitting or one that you’ll get done without anything else interrupting. For instance if you want to write up an essay but don’t finish it before bed, then the next day that’s your top priority.
  • Once you start tasks in a story, that story should (more or less) be your top priority. This lets you focus on delivering value. It also helps get the Story out of your mind. Remember, good breakdown means more stories with less tasks, and that makes this easier.
  • In all cases, try to focus on something being done and complete. Deliver value – or parts of value.

Sticking with something helps you stay focused and keeps you from the mental waste of switching gears over and over.  In a lot of cases it’s better to finish something and start the next thing unless you really have to.

How Do I Track Work?

You want to track the work you’re doing and to know what you’re up to and what you’ve done.  Here’s what I do:

When you start a task, move the “hours” estimate into the appropriate column, and keep moving it. This way you’re tracking work done:

  • Define – You’re fleshing it out and getting ready.
  • Developing – You’re doing it.
  • Review – You (or someone else) are confirming it’s done.
  • Done – Well, duh. Done. Congrats.

This is why I keep totals at on my spreadsheet so, at a glance, I know how many “hours” of work are done where. I’ll go into this more later.

One thing you’ll note is that I track the state of every Task (some methods only do stories). I find if you track and validate Tasks, the stories usually take care of themselves – a truly well made Task may not complete the story but is verifiable. It also lets me follow my progress in miniature as I’m pretty focused on this.

You may only need to check your progress story-level. You can use a pivot table for this, or other forms of visualization I’ll cover next.

How Do I Avoid Being Overloaded?

OK, here’s where we get a new concept: Work In Progress.  This is important.

Work In Progress, aka WIP, comes from Kanban, and has been adopted into many Agile practices, including, of course, some variants of Scrum. The core idea is to limit what you’re working on so you focus – and so you find blockages to completion.

It’s simple – you set a limit on how much work can be in each column (Define, Developing, etc.).  This is usually only one item.  I usually limit it to one task, but sometimes it’s limited to one story.  Nothing can move ahead until there’s “space.”

This idea of moving ahead only when there’s space is called “Pull.”  You don’t push items forward – you pull them when available.  I find this comfort is very comforting, it changes your focus on work.

But what if you’ve got a task in Developing, it’s done, but you have another task in Review waiting on approval? You don’t move that Developing task. It sits. You can either go Define a task and do some research, or try to get the task in Review, well, reviewed.

If all three are filled up? If your Defined thing is Defined, your Developed task is all developed, and you in-review task is in review? You should focus on the in-review task, but if everything is blocked, it may be time to take a break.

Now of course work may have to move forward, but you should acknowledge how you got blocked and fix it in the future. When things get jammed up that’s the sign of a flaw – and a sign you should change your approach so it doesn’t happen again.

Think this is tough? Some folks like to keep it down to one item being worked on period, no matter what the state. In fact, I’m an advocate, on the individual level, for doing this method. Sometimes I even succeed.

So what does all this stuff with Work In Progress Do?

  1. It forces you to avoid multitasking. Multitasking really distracts you, and the more you pile up half-done, the more you’re distracted.
  2. It rethinks work. The idea of “pull” of moving forward only when there’s space helps you see work in a more relaxed, appropriate manner.
  3. It reveals blockages and obstacles. Think of your workflow as a pipe system. If you restrict the amount that goes through it, when a jam up occurs you learn a lot. This is an enormous amount of Kanban – to the point where I’ve heard people say Kanban isn’t a management tool but just a way to find and remove blockages.
  4. It works better with good work breakdowns, so helps validate them.

Now because life gets complicated, I practice what I call WIP 1+1. That means the usual limit applies, BUT I allow myself to work on something else as long as I can get it finished in one go. This means if, say, something is sitting at my editors, I can go do some cooking or clean the bathroom. But I wouldn’t start something that may need another editor’s attention.

As noted, I do this on the task level.  You might find it works on the story level.

What If Something Takes Longer Than I Estimated?

That’s fine, that’s OK. It’s something to note for review at the end of the sprint.

If this requires you to cut work, fine. Figure what the least priority items are and don’t do them unless you suddenly have time. You’ll review this.

One thing I do is change my estimate to fit my new findings.

What If I Get Everything Done Earlier?

Well you could take a break. Otherwise, just bring the topmost items in from the Backlog into the Sprint Backlog, one at a time. Finish those items before taking something else off the backlog.

So This Is Just Taking A List Of Stuff And Trying To Do It Without Multitasking In A Given Timeframe?

Well, yes. Welcome to Agile, where we cut through the bullshit or break the bullshit into manageable pieces.

Next Up?

This may seem easy, but we’ll talk tools and visualization.

– Steve


My Personal Agile: Your First Sprint

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

Congrats. All that work last time? You’re ready to start a sprint in my Personal Agile. First, let’s review.

Last time you build a spreadsheet (or equivalent) to track:

  • The Incubator – All the stuff you want to do eventually.
  • The Backlog – You took the stuff that you really want to do out of the Inacubator, broke it down, and detailed it enough that someday you can do it.  These are things you’re very sure you want to get to.
  • The Regular Tasks – You detailed the things you have to do every month.

Pretty useful, right? Well get ready, here comes your first sprint. In fact, let’s talk what this is.

The Sprint

A Sprint is a concept I first got introduced to in Scrum. A Sprint is a time period (almost always the same length) in which you do work.  The Sprint is loaded up with your Regular Tasks and the top items in the Backlog – this is called the Sprint Backlog.  You then work on these items for the Sprint, and repeat the process.

The Sprint concept has a lot of advantages:

  • Each time you use the same span of work – it helps with predictability on delivery and figuring out how much work you can handle.  By the way, it takes a few Sprints to figure out how much you can handle.
  • You load a Sprint with the most important work, but usually figure out the best way to do it during the Sprint – it may not always be in order.
  • You focus on what you’re sure you can do.
  • You review and re-plan so you adapt – and if you screw up it’s only for a short period.

Sprints in general are not modified or changed when they start, though there’s often fiddling around the edges because you’re constantly discovering things. If a Sprint is radically restructured, it should be stopped and a new one begun, with everything replanned and re-evaluated.

Sprint Size?

So how big should a Sprint be?  In Software I see two weeks held up as an ideal, though in some past writings a month was apparently favored.  I see a lot of three week Sprints, and have heard of a few week Sprints.

For my Personal Agile I use a month. This is because:

  • For most of us our lives have a monthly cadence.
  • It’s large enough to deal with the unpredictability of life and not get derailed.
  • It interfaces well with other forms of time measurement – quarters and years.
  • Because of that interface it also ties well into things like college quarters or semesters, financial years, and more.
  • Yeah, months aren’t the same size, but it’s close.

I recommend starting with a month – and never doing a Sprint larger than one month. However, you may find that smaller ones actually work for you.

Why would you use a smaller Sprint?  I find smaller Sprints allow for more responsive development, quicker turnaround on changes, and more reviews.  It might work for you!

OK, let’s move on to . . .

Sprint Planning – The Sprint Backlog

Every Sprint I have a tab in my spreadsheet for work to do that month. At the end of the first month (or thereabouts) I copy my old spreadsheet (so I don’t loose records), and then start planning.

Sprint Backlog has these fields – which must be familiar.

  • DATE – If something is date-bound.
  • PROJECT – Obvious.
  • STORY – Obvious.
  • TASK – Obvious.
  • SIZE – The size of the project in hours.
  • DEFINING – This starts blank. When a task is being analyzed, you move it’s “hour count” out of “Size” and over to here.
  • DEVELOPING -This starts blank. When a task is being done, you move its “hour count” here.
  • REVIEW – This starts blank. When a task is done but not confirmed done (say you’ve got to get approval), you move it’s “hour count” here.
  • DONE – This starts blank. When you are done with a task, it’s “hour count” moves here.
  • NOTES – Obvious

As you can guess, I sum up Size/Defining/Developing/Review/Done at the bottom of the Spreadsheet. This lets me see, at a glance, where work is and what’s going on. How much work (in hours) is not started? How much is done?

Finally I sort this sheet by:

  1. DATE
  3. STORY

This way I see:

  1. What has to get done first.
  2. Then things by project.
  3. Then individual stories.

OK, you got your Sprint Backlog tab. Let’s fill it.

Filling The Sprint Backlog

You probably see where this is going, but . . .

  1. First, copy over your Regular Tasks list. Congratulations, you’ve populated your backlog with important stuff (and some months this may be all you get to)
  2. Look at the work for the month. Do you (honestly) have room for more? Anything suddenly get added or something you won’t do? Any holidays? Add or subtract things. It’s possible that you’ve covered most things you need.
  3. You may realize that holidays, events, etc. require more work.  So put in stories/tasks for such things.  It could be cooking dinner then throwing a party, or it could be you want to take a holiday to relax.  Make these things into stories/tasks so you know what to have to do and don’t overload yourself.
  4. If something is just fun?  Like a big event? I put that in too so I take time for it.
  5. Now, go into your Backlog and – you guessed it – take the highest priority story.
  6. Take that story and determine if it needs to be broken down any further.  This is your time to do a bit more analysis.
  7. Now do the same with the next item on your Backlog.
  8. Each time you take an item off your Backlog and break it down, ask if that’s enough work for the Sprint.  Eventually, you stop.

And that’s it. Its just like your Incubator and Backlog, only you’re using the Backlog to make a set of tasks and stories for your sprint.

In a lot of Scrum practices this process is timebound to four hours for a team.  I don’t really timebox myself, but I recommend 2 hours or less if you need a “boundary.”  This prevents paralysis through analysis.

By the way, you’ll do this every sprint. I find in time I get a very good idea of what’s next and this becomes easier and easier.

Congrats on the Sprint Backlog

There, you have a Sprint Backlog. You can start work. In fact, I’ll address that next.

– Steve


Steve’s Update 12/13/2017

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

It’s my weekly Scrum style standup for my audience, so what’s up?  Well, OK it’s late.  Sorry – long week.

So what have I done the last week?

  • “A Bridge To The Quiet Planet”: I’ve edited out to chapter 6.  My goal is an intial pass this month, taking a lot of notes, and the BIG rewrite will be January-Feburary, with a tightening effort in march.
  • Way With Worlds Minibook #6: Editor will have it to me this weekend and the cover is done!
  • Blog: I queued up more of my personal agile methods.
  • Other Stuff: Still doing holidays and career stuff and the usual.  I also loved the Disaster Artist!  There’s various things behind the scenes too.

What am I going to do this week:

  • “A Bridge To The Quiet Planet:” I want to try to finish this up before the week of Christmas, so really hauling on it.
  • Way With Worlds Minibook #6: Editing!
  • Other Stuff: Not much else planned except some Christmas shopping.


  • Not sure I’ll figure my sustainable writing pace due to the holidays, due to the various events and time off, but I am working on writing reguarly.  I figure between my past measurements and this I can work out a good pace.  Right now it seems to be about 40K – I also found editing something is equal to about 4x the amount of words – editing 4000 words is roughly “equal” to writing 1000.  I’m using that to measure pace too.

– Steve

My Personal Agile: Getting Started With Incubators And Backlogs!

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

OK, so we’re talking my personal Agile Method, which is really kind of Scrum with some variants and my own tweaks.   This is how I stay productive – without goung crazy.

I’ve talked Value. I’ve talked breaking down work. Now we’re going to figure out what work you need to do in the future. Literally, you can start now – this is the first phase of really getting into it.

Now a quick warning on what I’m about to show you:

    1. It’s best done in one go. That will likely be an hour – it can go as high as four.
    2. My “sprints” (periods of doing work) are one month long. So you may want to do this closer to the start of a month.
    3. It’s going to require some record keeping.
    4. It’s not entirely “standard” Scrum.
    5. You’re gonna do a lot of typing.

OK warnings done, let’s start.

Set Up To Track Work

First, you need a way to track work. Me, I use a spreadsheet with several tabs in it. I’ll assume you’re doing the same, using either Word or LibreOffice. You can also do this on graph paper or in a word processor table or whatever, but I like spreadsheets.

So spreadsheet in hand (well on computer), let’s go.  First up – the maybes!

The Incubator

The Incubator is where you track things you probably want to do but haven’t really decided when to do or aren’t ready to get to in the near future. It’s for “I really want to and probably will” but “not sure when I want to do it and have other priorities).

In a spreadsheet (or whatever method you do), every row represents something you’ll want to work on. The Columns to defines this work is simple:

  • PROJECT – The thing I want to do
  • NOTES – Any notes.
  • I also insert a “Rank” column to help sort them.

So your each line of your incubator is a thing you want to do and some notes.

You may also have notes and wireframes and prototypes on your computer. I can talk more how I organize that stuff later, but I suggest having one or two directories to store just project information.

Setup, done, let’s go!

So your first step is to write down everything you really are sure you want to get to for the foreseeable future. I recommend going out at least a year, but maybe more.  Don’t overdo describing things unless you have a lot of ideas, and keep separate notes on more elaborate plans.  When in doubt, use your friend the User Story:

As x I want to y so that Z.

Now as you write these down, try and put them in order of priority – Bit nothing can be of equal priority. This is called Force-Ranking and is a tool to help you (OK, make you) decide just what order you want to do things. It’s a great way to help you evaluate, challenge yourself – and even helps construct a vague schedule very quickly.

If you have any metrics or measurements of success, you might note them here, in separate documents, or even have a separate project to measure them.  For instance if you get a certification with the hope it adds to your paycheck, that’s a separate project – evaluating pay a year down the road.

Also it’s OK if you miss something. You’ll be reviewing this regularly and adding things you forgot – or subtracting things you no longer care about.

Once you’re done and you have a good list, in order of priority, of what you want to do, we’re going to get deeper.

The Backlog (or Backmap)

You now have a good idea of everything you might want to accomplish in the near future. Now you’re going to determine what you definitely want to accomplish. So we’re going to your Backlog – the “I’m definitely going to do this list.”

The Backlog tab of your spreadsheet should have the following Columns (warning, this is a lot)

  • RANK – How important the project is. I use Rank to sort (and unsort) columns. You might not use this.
  • DATE – I include dates I want to get things done by. Not everything will have this.
  • PROJECT – The name of the project.
  • STORY – The name of a story that is part of a Project.
  • TASK – Sometimes when you fill a Backlog, you even know the tasks involved. You may or may not use this column.
  • SIZE – Since I often do tasks in the Backlog, I size them in hours as noted. You might not size everything.
  • NOTES – Notes. You kinda got that.

So roughly, your Backlog is going to let you at least list all the stories you can think of in the Projects you want to do – and possibly some tasks.

Now let’s fill this backlog:

First, take the topmost item in your incubator. Evaluate if, indeed, this is something you want in your plans to do. If so, move it to the Backlog. This will, of course, be your topmost item – probably.

After moving, it, try and figure out any major stories and break it down further – with one line per story. Thus a small Garage-cleaning Project may have the following stories

  • Clean Out The Trash Cans
  • Buy Lots of Trash bags
  • Clean out the garage.
  • Call someone to haul the big stuff away.
  • Put out the trash.
  • Final dusting and cleanup.

You’d make one line entry for each of these with its Project, the story, and maybe even several tasks (each tied to a story).  However most of these stories are also probably “single task.”  You might list something like this:

These may not be perfect breakdowns, just enough to get a handle on them. If you can do more without wasting time, then go for it. I have lots similar projects with my book writing, so I can even break some Projects down to the task level from the get-go. Just don’t overdo it – or lock yourself in.

So after you put in your first big story, you go back to the Incubator and . . . pick the next one, and do the same thing. You put these stories after the ones from the first project because, hey, that project is the second most important thing, right?

Not necessarily.

Backlog to Backmap
This is where the backlog gets fuzzy because though it’d be nice to do everything in order, but you may not want to.

Agile is all about delivering value. However:

  • The value of all stories in a more important project may not always be more than some stories in a less important project. Remember stories should be relatively independent pieces of value.
  • Some projects can’t be done all in one go and/or need to be paced out. Imagine trying to write a book and that’s all you do to the exclusion of all else? It’s not like you can cook six months ahead then write for six months.
  • Some work is bound by other limits, including time.

So about by the second or third big project you put into your backlog, stories from different projects are likely to be in different orders than the projects were in the Incubator. That’s fine. The key is, as always, is value and what you can deliver.

My reccomendation is that when you first do this, try not to focus on getting projects done in order of prioritiy, and get comfortable with “mixing” their priorities as you get used to this.

Sometimes you have a lot of timebound stuff as well. When your backlog has a lot of date-driven Projects/stories I christen it the Backmap – as it’s also a Roadmap.

A note, by the way, on how to use the fields to make this easier:

  • Tracking things by PROJECT lets me sort and resort what’s going on and even check if a Project is done because there’s no other stories after the last (and lowest). I also put in a “completion/wrapup” story for any large projects to remind me I’m sure I’m done.
  • You also see the importance of RANK – you can easily sort or resort projects if you need to assign some numeric values.
  • Finally, you can see why I include DATE as that also helps me sort things. In fact one of my tricks is to make RANK the number of the month
  • I want to do certain Project/Stories in. Then after sorting, I can more finely arrange priority.

So you go through this until you have a backlog that covers the things in the Incubator you’re SURE you want to do. This probably won’t be all of them. For the first time what I’d do is just get enough Projects queued in and broken into Stories that you know what you want to do for the next three months.

You’ll be revisiting the Backlog monthly if not more anyay.

The Regular Task List

Wait, aren’t you done? Nope, because my guess is your life has a lot of things you do regularly. Meetings, cleanings, cooking, social events. You’ve got Regular Tasks, so it means it’s itme for the Regular Task list.

I set up the list the same as I do the Sprint Backlog (which we’ll get to) so I can copy it over easy.

It’s got the same columns you saw above.  Now that you did a Backlog/Backmap you’re probably going to find this pretty easy.

  • RANK
  • DATE
  • TASK
  • SIZE

So here’s what you put in:

  1. Anything that you do with a monthly cadence (possibly even quarterly).
  2. Use “Project” to organize it. For instance I usually have “Projects” like “Cooking” for all my cooking, “Social” for all my social events, etc.
  3. I use Stories to organize anything, but usually they’re the same as Tasks. Frankly, you may not need to use proper User Story style here. I mean “work out this week” kinda does it.
  4. I put in tasks since, as these are regular, I know what’s going on. Often they’re the same as the story as these regular bits of work are very defined.
  5. If a task repeats during a month, I make entries for each repeat. For instance I tend to cook 8 times a month or more. So I have a Project (Cooking), a Story (Cook #x) and a Task (Cook #x).
  6. For these repeating tasks make sure you break them down well. Improving and polishing your Regular Tasks is great practice.
  7. For Regular Tasks I try to break down the task small, down to hour increments if possible.

Setting up your Regular Task List is pretty good practice for what comes next – the Sprint Backlog. That’s the next post.

To give you an example, here’s how I handle my cooking:

  • A Project called “Cooking”
  • Eight stories called Cook #1-8 – since I want to make eight large meals to freeze up.
  • Each story has a task called – you guessed it – Cook.
  • Each story is sized to an hour.

And Here We Are!

So there you go, you just created, in (hopefully) a short time:

  • Your rough vision for the future in the form of the Incubator.
  • Your solid vision for the future in the form of the Backlog.
  • An idea of what you’ll do monthly and a good practice for the Sprint in the form of the Regular Tasks.

Next post we’ll talk about figuring out what you’ll do specifically – the Sprint Backlog!

– Steve


My Personal Agile: Work Breakdown

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

And back again with my attempt to describe my “Personal Agile” productivity methods.

One of the challenges of getting things done is to figure out how to get it done. What do you have to do? What order? How do things work together?

To figure this out part of most any Agile practice is breaking down work to find out what to do, how to do it – and maybe if it even needs to be done (by finding the value as mentioned earlier).

So here’s how I break down work – this is the last stop before we get on to the real hands-on work.

Please note, these are my own definitions, tweaked for personal productivity. They may not fit various other Agile methods or ideas.


At the top of this all are Projects.  Projects are major, often large, initiatives. These are usally the big things you want to do like cleaning the garage, launching a new website, or writing a book. It may even be a thing you do regularly like cooking twice a week.

How do you define a Project? Here’s a quick guide to what a Project is in my book:

  • Distinct. Projects stand on their own and have their own identity that is (mostly) not dependent on anything else.
  • Has one of two lifespans:
    • It is distinct and will complete and be done, such as finishing a book or a program. Note that something like a software program may then spawn new projects like “maintenance.”
    • It is a distinct effort that is continuing, like a software maintenance program or an exercise routine. I call these Regular or BAU (Business As Usual) Projects. The effort is distinct enough that you could decide to end this Project in the future as a discreet act
  • Usually large. Most Projects will be of some size. However I argue that the Distinction and the Lifespan together define a Project more than size. And since this is my method, I’ sticking with it.

Project Value:
How do you determine if a Project is worth doing – in short, it’s value? There’s formal methods used in business, but on Personal Agile I find that there’s two ways to express – and measure – it’s value.

  • The binary. “I want X so y.” It could be as simple as taking a vacation so you relax or getting a certification as it’s standard career progression.  This is a lot like a User Story (below) just jacked up a level.
  • The measure. This is when you can tie the value to a measure and thus by measuring, determine if something was done and worth it. If you got a certification to try and get a raise then you can measure if that goal was reached – and it can fail as you may get the certification but not the raise. If you want to make X amount of profit with a book in a year, you can evaluate it – after a year.

Because Project success can be defined in many ways, I always look for “congruence,” that gut-level feel that the Project and any measures connect to my life goals. If that gut-level feel isn’t there, you might be wasting your time – or doing this under duress.

By the way if neither work, you can try describing it like a Story.  In fact, those are next.


Projects consist of Stories. Stories are where we get down to real work and hands-on value. Stories are also where a lot of work and breakdown and arguing goes on. So get ready for some opinionated stuff that might get me into a fight with other Agile practitioners.

A Story is the smallest unit of work you can do in a Project that still delivers value and helps complete the Project. It may be of limited value. It may be to a limited audience. It may not be that helpful without other Stories. But it has value that wouldn’t exist if you took it apart any further.

Ideally a Story should, when completed, be valuable if all other work stopped. It might not be much, but it’s something. Note this is an ideal but it doesn’t always happen.

The best way to get to breaking down Stories is to try it.  So let’s try . .  .

EXERCISE: Look at a Project you want to do.  Now write down everything you’d need to do for it to get done.  Don’t get over-detailed, just give yourself about five minutes.  We’ll talk how to make good Stories in a moment, but I want you thinking breakdown.

Interesting isn’t it?  Determining stories is definitely an art.  I also bet that the Story breakdown you have just brainstorming isn’t quite clear or satisfying.

So if you’re thinking “These Stories seem both really defined and kind of fuzzy” you’re right. Agile is both knowing what to do but not overdoing and overanalyzing. Fortunately there’s a tool to clear them up – and it’s a core part of Agile and one of it’s big contributions to management thought period.

Story Value
Stories in Agile are sometimes called User Stories (the terms get thrown around interchangeably). This is because they are, bluntly, focused on delivering something (value) to someone (a user) – and that forms a Story. The formula is a key to quickly determining what a Story is and what it delivers is to title the Story thus:

As (person) I want (thing) because (reason)

Sound simple, right? But this tells you three things – why you’re doing something for whom. If you can’t figure out any of these three parts, you either need to break it down more, do research – or realize it has no value.

When you define your Stories this way, you get:

  • The Person- Tells you who you do it for, who to ask for questions, and who approves of the result. Vital for good feedback, communications. Though in Personal Agile this is probably you a lot.
  • The Thing – Tells you what to do. The better defined it is the better idea you have what to do but don’t overdo it.
  • The Reason – Tells you why. Why is a great guidance for evaluating what you do, determining if you’re delivering, and motivating you. Reason is also one of the major places where you discover “hey, this is kinda worthless.”

If you’ve ever done something and wondered “why am I doing this?” imagine how knowing these three things would have helped.

As you can see, the Story method is pretty powerful. Sure you might need more details, you may have to find them, but this is a great way to know enough to get doing things. It also helps prevent over-designing things.

By the way, if you need more details, let me refer you to the classic Kipling poem’s opening line:

“I KEEP six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.”

You got Who, What, Why. If you need more details see if any of their friends should go in: When, How, and Where.

By the way, when in doubt, yu can use this formula everywhere. To evaluate an action, to quantify a Project. So be it the biggest Project or the simplest task, when confused, ask “why an I doing this thing and for who?”

A few notes:

  • In Personal Agile you may not need to do formally described stories, but it does help. When in doubt, use them – they’re wonderfully clarifying, even if later you go back to more simple terms. If you’re new to this, definitely use them.
  • Some Projects are so big that they have “big stories” or “bundles” of stories called Features, Epics, Legends, etc. These let you organize stories into groups.  I don’t use them in my Personal Agile.


Tasks are the final part of good Agile planning and breaking down work. This is when you figure out what you do hands on.

Remember how you broke down Projects into Stories, the smallest bits of value?  Tasks are when you break down a Story to figure what you have to do to get that value.  Every Story has at least one Task, and each Task contributes to completion of that Story.

Figuring out Tasks is also a bit of an art, but is usually more hard-nosed than, say, Stories. You can pretty much look at a Story and figure out what has to be done.  Remember you may find more Tasks are needed, but you can usually get a good start.

There’s no real way to describe Tasks, but I’d describe them as clearly as possible for the sake of clarity.  The value of them is also pretty apparent as they’re directed to a goal.

EXERCISE: Look at one Story for the above exercise.  Describe the Tasks necessary to do it, and try to make them of reasonable size.

Interesting exercise isn’t it?  You can define Tasks but how do you get your hands around how much work they take?  That’s what’s next.

Tasks and size
Tasks are also where sizing takes place. Sure, sometimes people size Stories and even Projects in various ways (I don’t always in my Personal Agile so I won’t cover it). However, no matter what, how you size a task affects real work – so we need to discuss that.

There is a lot of discussion in Agile about how to do this. In turn thereare a lot of great ideas. In turn, a lot of people actually ignore these half the time. The other half they argue.

Me, I use hours of work. If I were planning a larger Project with more people I might use other methods, but in this case I have a pretty good grip on how fast I work.  This also lets me figure out how long I can spend on things and may let me track odd things that just require a block of time (if, say, I want to spend X hours studying)

However I do have an additional rule I call Fibonacci Hours.

I size tasks in how long I think they’ll take. But I have a few rules:

  • Tasks should be sized so in theory I can do them all in one go – even if it may take setting some time aside (usually 5 hours or less).
  • Tasks are sized in hours – minimum one hour.
  • Tasks hour-sizing must fall in the Fibonacci sequence – 1,2,3,5,8,13, etc. Basically each number is the sum of the ones before it. If something is “between” the two I have to make the call if it’s more likely the lesser or the greater.

In using these Fibonacci hours I’ve been amazed how accurate they are – usually more accurate than my attempts to figure the “exact” time. This is because in our ability to estimate, we’re not always good making fine distinctions, especially with larger numbers. This just enforces a pattern that, as a story gets larger, you have to think in a wider range between sizes.

By the way, I try to break things down to never be more than 3 hours, 5 at the most, unless it’s for something odd (like setting aside time to write).

By the way if you use Agile, you’ve seen this used for “points” and other methods of work. I just found they worked for hours.

A Few Tips On Tasks

  • In an ideal situation each Story would have only one task because you were able to break down value so specifically.  This can happen a lot in Personal Agile, but not as much on larger Projects.  It’s something to aim for, but remember it may not be achievable for certain efforts.
  • It’s best to describe tasks well, but in Personal Agile usually you’re the one doing them so don’t waste time.  Just make sure you can remember what you described.
  • A few times above I noted sometimes a task is just spend-so-much-hours on something.  Don’t be afraid to do that – in Personal Agile it really helps.

Onward To Action

OK you know to think about value. You have an idea of how to break down work. Now we’re gonna get started.

By the way, even if you never use any of my other Personal Agile methods, thinking about work like this will help you.

– Steve


Steve’s Update 12/4/2017

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

It’s my weekly Scrum style standup for my audience, so what’s up?

So what have I done the last weeks?

  • “A Bridge To The Quiet Planet”: It is DONE.  I finished the book, and am now editing it.  There will probably be 3 passthroughs – this one is fleshing it out and tightening the plot – and Chapter 1 is already edited.
  • Way With Worlds Minibook #6: Waiting on my editor now.
  • Sales: Post-NaNoWriMo Fan To Pro is on sale!
  • Blog: I started a new series on my personal agile methods.  Be sure to read it – and I’ll wrap it up as a book.
  • Other Stuff: Lots of early Holiday stuff, and a lot of behind-the-scenes planning, marketing, etc..  I’m still gearing up for the next year, including doing some side projects.

What am I going to do this week:

  • “A Bridge To The Quiet Planet:” Editing a few more chapters.
  • Way With Worlds Minibook #6: I hope to get it back from the editor!
  • Other Stuff: Seeing the Disaster Artist and relaxing.  I’ve GOT to find time to the 2-3 generators I have in mind.  I also have a request for a book cover.


  • Not sure I’ll figure my sustainable writing pace due to the holidays, due to the various events and time off, but I am working on writing reguarly.  I figure between my past measurements and this I can work out a good pace.  Right now it seems to be about 40K – I also found editing something is equal to about 4x the amount of words – editing 4000 words is roughly “equal” to writing 1000.  I’m using that to measure pace too.

– Steve

My Personal Agile: Value

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

I’ve been talking to a few people about my personal use of Agile (specifically Scrum) to be productive.  So let’s get to the next step: thinking about work.

It may seem strange to say your first step is thinking different – it sounds kinda fuzzy doesn’t it? But it’s it’s a core part of Agile methods, and a core part of doing better. How you think about work affects how you do it – or if you do it. Agile is not just some techniques or some airy philosophy – it’s a mindset.

First up is learning to think about value.


Value is something talked about in Agile a lot. The first Agile Principle is:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Substitute software for, well, anything. Substitute customer for whoever your target audience is – including yourself. Your goal in doing anything is to do something of value for someone.

If there’s no value, well the eight Agile Principle states

Simplicity–the art of maximizing the amount of work not done–is essential.

So if something isn’t worth it why do it? Exactly – don’t.

If there’s no one to do it for, don’t do it.

But, that means you have to learn to think about the value of work you do.  I’ll cover more of that in the next section when we look at breaking down work.

EXERCISE: List the top five things you want to get done in ife. Write down in order which is the most important to the least – and no item can be of equal importance to any other (this is force-ranking). What do you learn doing this?

EXERCISE 2: What was the last thing in life that you did that really didn’t need to be done. Why did you do it? How much time would you have saved not doing it?

Value And My Personal Agile

So why is value so . . . valuable? I mean you can guess, but let’s peek behind the curtain.

  • Thinking about value tells you why something should be done – and you can figure out if it’s worth doing.
  • Thinking about value tells you how important something is – and how you should prioritize it. Good productivity – and Agile especially – requires you to know what’s important to do. That helps you organize.
  • Thinking about value tells you who wants it – and that’s the person you want to talk to for guidance and feedback.

The first part of work is knowing why you’re doing it – or why you shouldn’t.

I hope that helps you think about work better. Because next step we’re going to talk about how you break work down – and find its value.

– Steve


My Personal Agile: Introduction

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

All right people, money where my mouth is time.  I’ve been talking to several friends and my girlfriend about my use of Agile methods (Scrum specifically) at home.  They’re curious, but they noted it’d be easier if I wrote this up.  Realizing I’m a writer I felt kind of dumb because, you know . . . I should have thought of it.

So guess what you’re going to see for the next few weeks?  That’s right – a detailed (but light) guide to my own Personal Agile system readable by normal humans.

Now let’s talk Agile, but first . . .

If You’ve Used Agile:

Don’t worry this isn’t fanatic or preachy stuff.  I come from an engineering and science background, bits and bytes and blood and guts.  I’m interested in results.

However I am big on learning and making good productivity part of everyday behavior.  That might get annoying.

You can probably skip the next section.

If You Haven’t Used Agile:

So what’s this Agile stuff?  Let’s go to a basic outline that is hopelessly minimizing everything but still useful.

  1. Formally or informally a lot of management and productivity has been top-town – orders, schedules, hierarchy, etc.  You get the idea – build a plan and follow it.  These days this is often called “Waterfall” but the basic idea’s been around for most of human history, and “Waterfall” as a concept is a comparatively recent invention.
  2. For a few decades at least (and informally throughout human history) people also have known this whole plan-it-then-try-it method doesn’t work.  Methods of alternate management and workflow have been developed.  Many are older than people realize, but were in specialized markets.  Look up the history of Kanban sometime.
  3. Software really seems to have blown the lid off of a need to find new ways to organize.  Software jacks all the problems of doing any task up to 11: it’s fast, it’s variable, it’s evolving.  A lot of methods to make software management and productivity work better evolved, and people started calling these collectively “Agile.”
  4. In 2001 a whole bunch of Agile people met at a resort to discuss this and produced the Agile Manifesto and the 12 principles, which are seriously worth reading.  This really consolidated and kicked off Agile practices – Agile had a Philosophy, and there was feedback between Philosophy and Methods.
  5. Since this time, people have been adapting various forms of Agile all over.

So that’s it.  People knew traditional management didn’t always work, software really revealed that and drove people to fix it, and from that emerged a more coherent philosophy that sent things into overdrive.

EXERCISE: Go to the Agile Manifesto and read it.  How do you apply (even if accidentally) the four core elements of it?

EXERCISE 2: Read the 12 Agile Principles.  Which make sense to you and which don’t.  Why?

Why Is Agile Different From Other Methods?

(Hey those of you who have used Agile?  You can keep reading now).

Here’s how I see Agile differing from other methods of getting organized that aren’t, well, Agile?

  1. Agile focuses near-obsessively on value and why you’re doing something.  As you may guess, Agile also helps you realize when something is stupid.
  2. Agile focuses on adaptability and responding to – even embracing – change.  This helps you get the most out of change, even when unwelcome.
  3. Agile is heavy on feedback and adjustment and review.  Improvement is baked in.
  4. Agile is about everyone involved practicing it.  This is why I think the Agile Manifesto is so important, it was a basis for people not just doing Agile but becoming Agile.

Cool, So What’s This Scrum Thing?

Scrum is one of the Agile Methodologies or Practices (I see people use the terms interchangeably).  It was my first encounter with Agile, and frankly I consider it and the older practice of Kanban (which I use parts of) to be the best stuff I’ve seen.  Yes, I’m biased.

At a high level, Scrum works like this:

  1. You keep a list of things you want to do in priority order.  That’s the Backlog.
  2. You set aside a block of time to do work, called a sprint.  This is often two weeks in software, but I use a month for myself since my life has a monthly cadence.
  3. Every sprint you look at your Backlog and take all the things you can do from the top down.  You do not skip an item unless it turns out something is more important.  Basically you take the most important things that you can do in that timeframe – that becomes your Sprint Backlog.
  4. You do the work and adjust and adapt.  Sometimes you find that there are issues, sometimes you find old work.  Sometimes you even find you have more time and grab more to do – off the top of the backlog.
  5. At the end of the sprint you figure out how you did, look over the backlog, and do it all again.

Scrum hits a sweet spot of “free-form” and “organized” for many.  You can predict work done more or less.  You know priorities.  If anything goes wrong you review every sprint and can navigate.  You also know what’s expected of you (or from yourself) in a timeframe.

You can probably see how this helps out.  When I implemented my own Personal Agile, which is mostly Scrum, I actually got everything done within the first 3/4 of the month.  I had a gain of 25% productivity – and I was already pretty productive using the Agile-sih “Getting Things Done” method (which is well worth reading up on).

EXERCISE: If you were more efficient – without overloading yourself – how much more do you think you’d get done?  Can you put a percent of gain you think you’d experience.

So What’s Coming Up?

Fine, you got the backstory.  Let’s get to the methods – next up we talk why things matter.

– Steve


Steve’s Update 11/26/2017

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

It’s my weekly Scrum style standup for my audience, so what’s up?

So what have I done the last weeks?

  • “A Bridge To The Quiet Planet”: I  posted the middle chapter and pushed it to do a lot of writing.  More below!
  • Way With Worlds Minibook #6: Not much, just waiting on my editor.
  • Sales: For the end of NaNoWriMo I’m putting The Power Of Creative Paths on sale!
  • Other Stuff: Well, mostly Thanksgiving and trying to relax.

What am I going to do this week:

  • “A Bridge To The Quiet Planet:” Finishing it of course!  That’ll give me four months to edit over the three I had planned.
  • Way With Worlds Minibook #6: I hope to get it back from the editor!
  • Other Stuff:  Some early Christmas stuff this week.  Nothing too noteable.


  • Continuing to push my ability to write.  I’ll probably hit 50K words this month despite not being in NaNo.  I’ve learned how much I can push myself, the next goal is finding what my sustainable pace is.  However that’ll probably take me past the holidays to do as those aren’t typical times.

– Steve