planning

My Personal Agile: Getting Started With Incubators And Backlogs!

by

(This column is posted at www.StevenSavage.com 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.

Onward
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
  • PROJECT
  • STORY
  • TASK
  • SIZE
  • NOTES

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 Agile Life: Overwork

by

(This column is posted at www.StevenSavage.com, Steve’s LinkedIn, and Steve’s Tumblr)

(My continuing “Agile Life” column, where I use Scrum for a more balanced and productive life continues).

Uhg.  So as you know from my blogging about agile techniques, I’ve been getting overloaded.  I’m trying to fix this with some success.  So here’s what I’ve been trying.

  • Velocity.  Velocity, the measure of work done in a timeframe, is a big part of Scrum.  One reason to measure it is to see what you can do – but another is to make sure you’re not overloaded.  I can tell my usual workload doesn’t quite work out, so I’m trying to reduce it a bit here and there.  EXAMPLE: Restructuring how much I put into a given project a month.
  • Effectiveness.  Do things better.  I’ve found you can also save time just by doing stuff better.  EXAMPLE: I made graphic templates for upcoming graphic work.
  • Letting go of the schedule.  Work done on time doesn’t matter if it’s poorly done.  You have to re-evaluate and re-assess your schedules and in some cases dispose of them entirely.  EXAMPLE: I had some library donations to make that kept getting interrupted, so I had to accept “it gets done when it gets done.”
  • Iterativeness.  The flipside of efficiency is to not try to be perfect.  Some things are iterative, things you do over and over or regularly.  These can be improved, or mistakes compensated for.  EXAMPLE: Cleaning.  If I miss a hard water stain in the shower it won’t kill me as I’ll fix that next week.
  • Capture.  Be sure to capture any big blocks of time you want to use for something.  EXAMPLE: I have some convention speaking coming up so I literally put it in my schedule as a big block of time to note “I will be doing nothing else then.”
  • Sizing.  I’m sticking with the Fibonacci numbers for sizing my work – in hours – as it seems to produce better estimates.

I’ve also looked at things that mess up my planning and scheduling and productivity.  The Antipatterns.  They are

  • Loading Up.  When you find your maximum velocity of work, it doesn’t mean it’s what you should do.  It’s what you’re capable of when you push yourself.  What is you sustainable rate?
  • Lumping.  When possible break things down so you can calculate your workload – and because it lets you adapt better.
  • Missing lumps.  Some things are just purely about a time commitment, like “setting aside X hours to relax.”  Some things are better lumped together just so you’re not micromanaging.
  • Not looking at value.  When you do something ask what makes it useful – believe me there’s some surprises in there.
  • Bad Deadlines.  Again, deadlines should serve quality, not the other way around.
  • No goals.  When you don’t have goals, you can’t plan.  We often substitute panic, deadlines, etc. for goals – those aren’t goals.  Goals are positive.
  • Done over quality.  Doing something fast poorly can be worthless.
  • Rigidity.  Agile methods are about embracing change, and if you have to keep things rigid, you’re not Agile.  You need to find ways to be adaptable.

Hope these help you out.  Something to look out for in your own life – and anyone you manage.

(By the way I do plenty of books for coaching people to improve in various areas, which may also help you out!)

– Steve

Steve’s Agile Life: Writing Time

by

(This column is posted at www.StevenSavage.com, 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