My Personal Agile: The End-Of-Sprint Retrospective

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

So your sprint is done. Congrats. Now it’s time for the Retrospective!

The Retrospective is a big part of Scrum, and there are variants of it in a variety of Agile practices. It’s simply sitting down and asking yourself “how did it go,” finding things to improve, and improving them.

It sounds simple, and it is. That’s the point. It’s an obvious, common sense thing to do is regularly review and improve. It’s just not common enough in practice.

Think of it this way, it’s great to stop now and then and decide how to get better. You just gotta make room to review and improve, and Scrum – and my personal-life implementation of it – make it explicit.

So here’s what you do.

The Retrospective

First, set aside time for the Retrospective.  It should always be timeboxed, and I use an hour.  If it doesn’t take an hour, fine – if it does, well you stop anyway.

Here’s how I review in a Retrospective:

  • First, ask yourself what worked. What kept you moving forward, getting things done, and what did you do right? It’s good to focus on the positive here, because if you do enough stuff right you’ll do less wrong.
  • Secondly, ask yourself what went wrong. Focus on specific things that went wrong that are improvable. There will be stuff, trust me.
  • Third, ask yourself what work you couldn’t get done and why. Note that’s not necessarily a wrong – maybe something wasn’t needed. But it let’s you figure out specifics.
  • Fourth, ask yourself what work you discovered you had to do that you didn’t realize. Always good to keep yourself aware of surprises.

You probably have a lot of stuff. But now you gotta make it actionable. What I usually do is list down all the items above, prioritize them, and work in addressing what I learned (good and bad) in actionable items.  Don’t just “not” do something, focus on doing better.  Take a good thing and find ways to repeat it.

As you come up with actionable items, there’s a few ways to record them so they get done:

  • New tasks in the Regular Tasks list. Often undiscovered work in my Personal Agile is something that reguarly occupies time at specific intervals.
  • New things in your backlog or incubator – say if you want to edit better, set aside a few hours to read up on it.
  • Habits you need to improve. I keep a list of what to improve and review it every few days.

Sounds overwhelming? It can be. So focus on the important things that you know you can address.  Don’t overload yourself.

You’ll catch it next time.


Velocity is a measure of how much work you got done in a Sprint.  As you examine Velocity over time, you learn how much work you can take – maybe.  There’s a few arguments about how to apply Velocity in Agile, so I’m going to give you my opinions.

Here’s how to get and use Velocity:

  • Measure how much work you got done in that sprint. As noted I use hours of work.
  • Keep a record of these hours per sprint (month). I keep a list in the same spreadsheet as my tracking lists. This lets me compare month to month and make notes.
  • This gives you a rough idea over time of how much work you can get done at a given time.
  • * As you plan sprints, look at your past Velocities to help you decide how much work you can do. This keeps you from overloading – or underloading – yourself.
  • It helps you keep a reasonable amount of work, creating smooth, regular productivity.  Note that’s helps because . . .

Here’s the thing, you can’t be sure the numbers are always perfect.  Velocity is a guide, but each month is different, from holidays to illness to vacation.  Each task is different, and sometimes things that take the same time can be mentally taxing or better done in different situations.

So I use Velocity as a a check, a suggestion, and a way to catch me overloading myself.  But each sprint I also do a gut-check if I can really handle the workload I want to do, for those given tasks.  Velocity is just one tool – but a good one.

What’s Next?

What’s next? Your retrospective is done. Time to end the sprint and start a new one!

– 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 Agile Life: Review Lets You Get It Right; Review Lets You Let Go Of Perfection

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

More on my use of “Agile” and Scrum in my life!

Perfection is the nemesis of success. The Perfect isn’t just the enemy of the good – sometimes the good is the enemy of ever accomplishing anything. Trying to get everything right can kill you, and sometimes even trying to get it really good is a barrier.

Sometimes you just have to complete something, review it, and improve it or do it again. Reviews are what let you get things done right – not trying to be perfect (which is not the same as being competent).

I learned this in my Agile Life efforts in, of all things – cleaning.

Cleaning is a regular effort – Business As Usual if you want to use bizspeak. It’s also something that may not always go perfect, from a difficult stain to not having a box to throw junk in. It’s also hard to get right as there’s always something else to do if you want to get obsessive.

So I had to do some cleaning and encountered a difficult issue in, of all things, the shower – nasty little stain. I didn’t have the proper cleaner, it seemed ridiculous to run out and buy it for five minutes work, and . . . I let it go. I’d get the stain cleaner at my next grocery run and get it next week.

By accepting yes, this stain wasn’t going to be a disaster, I avoided a half hour of running around for five minutes work I did the next week. Plus I learned to keep certain cleaning supplies on hand.

An agile way to do things – learn and improve and don’t sweat every detail. Delivering, review, and processing what you learn means you get better and waste less time.

Now cleaning is kind of a ridiculous example, but consider other places this applies:

  • If you’re writing something there’s only so right it’s going to be. That’s what editors, pre-readers, and just regular improvement will bring.
  • If you’re decorating the apartment do not think you’ll get it right the first time. Do your best and review it.
  • If you’re working on a web page and a photographer is late maybe you can make due with current photos – or what they sent you.

Finally, I’d note that if you’re doing something regularly – updating a website, cooking, etc. this is a REALLY good place to learn to let it go. Things that might not be perfect can get a bit more perfected next run.

I’d refer to the 10th Agile principle here: “Simplicity–the art of maximizing the amount of work not done–is essential.”

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

– Steve