(This column is posted at www.StevenSavage.com 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:
- DATE
- PROJECT
- STORY
This way I see:
- What has to get done first.
- Then things by project.
- 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 . . .
- 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)
- 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.
- 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.
- If something is just fun? Like a big event? I put that in too so I take time for it.
- Now, go into your Backlog and – you guessed it – take the highest priority story.
- Take that story and determine if it needs to be broken down any further. This is your time to do a bit more analysis.
- Now do the same with the next item on your Backlog.
- 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