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?
- It forces you to avoid multitasking. Multitasking really distracts you, and the more you pile up half-done, the more you’re distracted.
- 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.
- 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.
- 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.
This may seem easy, but we’ll talk tools and visualization.