October 16, 2015

A Personal Kanban & a OneNote Folder for Every Client, Project, Aspect of Life

For the last couple years I have almost always had 5 to 10 active Personal Kanbans in Trello along with a folder in OneNote and another in Outlook or gmail (one for each PK). I have one of these trios for each client. I also have a trio for personal/home projects and another for church projects. I can access all 3 of these on my Mac, my windows laptop, and my Android phone. Sweet!

I'll generally work on one client or one project per day, or for a week, or even a month at a time. Whenever I finish for the day I endeavor to ensure my PK and notes pages are all up to date and in a state that will help me pick it back up tomorrow or some other day. Whenever I switch contexts, it's a simple matter to switch which Trello board and which OneNote folder I'm viewing.

I really like the way these work together. It's helping me become paperless which is a bonus given my travel and the number of notes I need to search for (and the sloppiness of my handwriting). This approach has segregated notes and tasks and emails into specific views so that I don't get distracted by what I don't need to focus on at the moment.

Seeing people take notes on a laptop, or open laptops in general, can be off-putting to many people. This is especially true when working with many different people or with a newish client, where we're still gaining trust and feeling each other out and haven't had many (or any) interactions yet. So I tend to take notes on paper whenever I'm having a conversation in person. Then I'll transcribe what is important of those notes into my PK or OneNote. Rewriting them (I'm told) helps to digest, consolidate, and remember what is important, a skill I never got the hang of in school. Many of my colleagues use those fancy pens to record handwriting and automatically convert it to text. I can see the benefit of that, but I'm a late adopter of new technology, due in part to being overly frugal. (I used a paper PK for a long while, until I found Trello.) I think I'll stick with manually reviewing and transposing the notes for a while.

All of this has gotten my life very organized. David Allen's Getting Things Done has helped too, but I've covered that in a prior post.

This may be the fastest blog post I've ever cranked out, one of the few I've cranked out in one sitting. I didn't know where the post was going to go until I wrote it. I just thought I'd share something about this system since it's been so powerful for me. I figured there was a blog post to be written about this, but I didn't/don't know what my readers would want to know. 

What have I not covered that you'd want to know?

September 11, 2015

What do you estimate and when do you do it?

Pick up most any book on agile or Scrum and see what it says about planning a product backlog or planning a release or about computing an end date for a project. It will say to identify the stories, estimate them in points, add up all the points, and compare the backlog point total with your velocity to figure out how many sprints it will take to implement all those stories. Then reserve some room for unknowns and for changes (agility).

So, that implies identifying and estimating stories far enough in advance to match whatever your planning and commitment horizon is. This implies that estimating story points in sprint planning or just before sprint planning or even one sprint in advance is likely not far enough in advance unless you are ultra-agile and aren't making commitments or setting date expectations more than a couple weeks out.

Most companies I work with have a planning horizon that is 3 to 6 months out. So, we put together a 4 or 6 month plan. That plan is going to be based on what we can know in advance, namely, user stories. (Sometimes we do this at the feature level, but that's another blog post.) We won't know research stories or spikes or defects or production support in advance. Whatever goes into the plan is what should go into the velocity metric. Stated differently, you shouldn't put anything into your velocity metric that you can't plan for 4 to 6 months in advance. Which means you shouldn't bother putting points on defect or on research stories. If you are going to compare apples to apples, your velocity must exclude unplannable stuff.

That's why I put points only on real user stories. Here is a series of blog posts I did on each of these topics:

Now, some people try to estimate this unplannable stuff. They try to quantify it in points and include it in placeholders in their plan. You absolutely should track this unplannable stuff, and you should reason about whether it will be more or less in the future, but trying to back it into points or plan it using points is folly. 

February 26, 2015

Don't Spike Defects

I've recently seen a small number of teams create Spikes for defects. That seems strange to me. If you have a good reason for doing this, please let me know.

It should be rare that we’d have a spike to research a defect. Defects almost always have some amount of unknown research and debugging to them. It would seem strange to me to have a SPIKE to debug a problem which would then be fixed under a Defect.

The exception case may be if we want a triage/debugging step where we figure out what’s wrong and estimate the effort to fix before agreeing to fix it. But typically with defects, once you know how to fix it, actually fixing may be faster than all the debugging. By the time you’ve got it debugged, you know exactly how to fix it. I rarely find that approval step necessary these days.

I haven't heard of spiking defects discussed in the agile community so I assume it's generally accepted that this is not a recommended or common practice.

February 12, 2015

How Many Stories per Sprint? Rules of Thumb

I'm often asked how many stories you should have in a sprint. People are looking for guidance.

I've heard some coaches recommend “3-6 stories per iteration per developer”. That's a bad rule of thumb. For a team of 7 developers you would have over 20-40 stories which is likely way too many. That kind rule of thumb also subtly takes the focus off of swarming and puts attention toward a developer per story, a story per developer.

My rules of thumb:

5 to 15 stories per sprint are about the right number, particularly for the clients I often work with in which there are maintenance teams knocking down a backlog of small defects and teams doing Web work with lots of small changes to do. 4 stories in a sprint may be okay on the low end from time to time, and 20 is an upper limit for me.

Most stories shouldn't take more than half the sprint to develop and test. Having 1 story each sprint that takes more than half the sprint is about all I would advise, and in that case all the other stories should be very small. For a 2 week sprint, it's better if every story can be completed in 1 to 3 days. (Adjust that for longer sprints.)

I need to elaborate on my comment that it's better if every story can be completed in 1 to 3 days. After stating that I'm often asked whether that's the developers working independently or all together. The answer is "whatever you are doing today." It is best if the team can swarm stories such that multiple developers can work on a story at the same time. If  2 or 3 devs can work on a story at the same time, then you can have larger stories finished within that 1 to 3 day rule of thumb. But if the team isn't there yet, if that's not the way they work today, then having stories that are too big given the way they are working is counter productive.

What's the maximum number of points for a story? How big is too big? How many points is too big for a story varies according to the team's pointing scale. I've known teams that start with 5 (5, 10, 20, 30, 50, 80). For them, 50 and 80 were too big. I've also known teams where a 1 point story would take less than half a day. For them, a 13 might not be too big. If a 1 takes more than a day, then 13 is probably too big. Generally, too big is an order of magnitude larger than the typical small story.

Here's an example: Assume my 1 point story takes a day or two and once in a while we have something that is truly tiny and we call those half a point. The 1 pointer is my typical low end of the range. I have something smaller, but it's not typical. A 13 is an order of magnitude larger that 1 point story. It's very difficult to keep the scale linear when there is that much diversity in your story sizes.

February 10, 2015

Story Splitting: Where do I start?

I don't always follow the same story splitting approach when I need to split a story. It has become intuitive for me so I might not be able to write about everything I do or what goes through my mind or how I know. But I can put here what comes to mind at the moment:

Look at your acceptance criteria. There is often some aspect of business value in each acceptance criteria that can be split out into a separate story that is valuable to the ProductOwner.

Consider the tasks that need to be done. Can any of them be deferred (to a later sprint)? If so, then consider whether any of them are separately valuable to the ProductOwner. If so, perhaps that would be a good story to split out.

If there are lots of unknowns, if it's a 13 because of unanswered questions, make a list of the questions and uncertainties. For each, ask whether it's a Business Analyst (BA) to-do or a Tech to-do. Also ask for each whether it's easy and should be considered "grooming". If it's significant enough and technical, maybe you should split that out as a ResearchSpike. Then make an assumption about the likely outcome of the spike, or the desired outcome of the spike, note the assumption in the original story, and reestimate the original story given the assumption.

Look in the story description for conjunctions since and's and or's are a clue that the story may be doing too much. Consider whether you can split the story along the lines of the conjunctions.

Other ideas:
  • Workflow steps: Identify specific steps that a user takes to accomplish the specific workflow, and then implement the work flow in incremental stages
  • Business Rule Variations
  • Happy path versus error paths
  • Simple approach versus more and more complex approaches
  • Variations in data entry methods or sources
  • Support simple data 1st, then more complex data later
  • Variations in output formatting, simple first, then complex
  • Defer some system quality (an "ility"). Estimate or interpolate first, do real-time later. Support a speedier response later.
  • Split out parts of CRUD. Do you really really really need to be able to Delete if you can Update or Deactivate? Do you really really really need to Update if you can Create and Delete? Sure, you may need those functions, but you don't have to have them all in the same sprint or in the same story.
Some of the phrases in the above list may have been inadvertently recited from Dean Leffingwell's book "Agile Software Requirements".

January 20, 2015

Airplane Etiquette: 12 Rants

How about a little airplane etiquette?

Surely my readers don't commit any of these blunders, so my suggestion is to print a copy of this to bring on board. This works especially well because those who have a lower airline status tend to be more unaware. Slip this in a seat-back pocket in the row in front of you before the others board. This paragraph won't (shouldn't) print with the rest of the page.

Here's my rant for the year.

# 1 - Avoid cologne and perfume. Many people, like me, are actually allergic to cologne and perfume. Our sinuses get stuffy, we get a headache, and our eyes start to itch. Very uncomfortable for a flight of any duration. Use Beano®. Use deodorant. But don't try to mask it with cologne.

# 2 - Before reclining your seat, look back first to see if you're going to squash a laptop or bump a head. Give a polite warning. Then recline your seat back SLOWLY.

# 3 - Don't flop down in the seat. Doing so can crush whatever is going on behind you.

# 4 - Don't punch the seat-back display. The person in front of you can feel the lightest taps through the headrest.

# 5 - Similarly, the person in the seat in front of you can feel everything you shove into the seat-back pocket, especially if you let the elastic on the net snap back. (I'm a big offender for this one. I'm working on being more considerate.)

# 6 -The middle seat armrests belong to the guy in the middle seat. The window seat has an armrest by the window… AND the window. The isle seat has an armrest at the isle… AND the isle. The only thing the dreaded middle seat has is… nothing. Give the poor sap in the middle a couple of arm rests.

# 7 - Ugh, a plane full of roller-bags. I wish the airlines would charge for carrying on more than 1 item and for any item that's the size of a roller-bag. Checking bags should be free. Come-on people. Let's travel light out there.

# 8 - The window seat has the prerogative to raise or lower the window shade as desired. Still, it is polite, but not required, to consider the others. Lowering it a little is kind if others are watching a movie, using their laptop or sleeping. Raising it for someone reading a book is a kind gesture. If you aren't by the window, ask very kindly if you'd like the shade adjusted.

# 9 - Turn off the ringer and alert tones on your phone. Completely. There are enough dings and beeps on the plane. We don't need phones beeping and dinging for every email that arrives and meeting that we are missing. Keep your reminders to yourself.

# 10 - Unbelievably, I see people play movies, games and music on planes without headphones. Some yack on the phone loudly while boarding, sometimes even on speakerphone. Use headphones. Speak softly.

# 11 - Pay attention. If you intend to wrap up in a blanket or a big coat and sleep, ensure that you haven't thrown the end of your cover over onto another person.

# 12 - Sometimes flight attendants will suggest we stay seated after we reach the gate to let those with tight connections off first. Certainly, if we're arriving late, I support that. If we're arriving on time, I'm not so sure. I don't have a lot of sympathy for anyone booking a flight that doesn't give them sufficient time to make their connection. I should probably rethink that. There could be people who got a tight connection because of some other canceled or delayed flight, or some fault not of their own. Yeah, it's good to be considerate.


Bring an orange. Eat it on the plane. The smell of citrus is most often welcome on a flight.

November 21, 2014

Repair a Leaky Cuisinart

My Cuisinart Grind and Brew developed a leak. There was a small hole in the plumbing. It would leak all over the counter. That made it more of a Cussinart in my household. Here's how I fixed it with a little metal epoxy that I got from the local hardware store.

Most of the posts I see online about leaky Cuisinarts blame a clogged thermos lid, using too much coffee, using too finely ground coffee, or a clogged filter. If yours is leaking clear water like mine did, the problem isn't any of those. Before I opened it up I suspected a leaky hose or a cracked reservoir (though there really shouldn't be any reason for the reservoir to crack).

There are 4 hex or torx-bit screws holding the bottom panel on. My tools weren't skinny or long enough to fit in the narrow hole, so I just drilled the holes out. I probably used a 7/16" bit.

When I opened it up I saw a rusty (and cheap) clamp on those big orange hoses. I thought that might be the problem. But I also saw some discoloration in a spot on the aluminum pipe. Now that I had the bottom off I filled it up with water to find the source of the leak. I saw that it was leaking from the aluminum. So, I sanded the area of the leak and cleaned it off. That made the hole more visible. I patched it with some epoxy made for metals that I got from the local hardware store. The smallest size cost $6 and is much much more than I'll ever need, but that's cheaper than a new Cussi..., er, Cuisinart.

Since I drilled out the bottom I can't just reattach it with the original screws. I'll use a little glue (not too much) to hold the bottom on. Superglue might work. JB Weld would work well. Some other assorted craft glues that I have lying around should work.

If yours has a leaky hose, that should likewise be an easy fix. You can get a new hose from your hardware store. Zip-ties and new clamps are easy to come by.

Good luck! Let me know if you find this useful.

April 8, 2014

My Recent Posts on LeadingAgile

I started working with LeadingAgile in 11/2012 on some complex enterprise agile transformations and other lean management consulting. Related to that, I've done most of my recent blogging over there on LeadingAgile's blog. Here are some of those posts:

I Don’t Estimate Software Defects, but it's not as simple as just that. If you follow my advice, you'll also have a zero-defect mentality and you'll fix defects as soon as you find them. In general, I want a conservative measure of velocity, so I don't record in my velocity anything that was unplanned. Therefore, I likewise Don't Estimate Spikes.

I'm fond of The Theory of Constraints and Brooks’ Law. In that post I evaluated Brooks' Law in light of the Theory of Constraints in a way that I hope helps the reader understand both concepts.

Lack of Predictability is Your Biggest Problem. The senior leadership in most organizations I work with seem to agree. They aren't very interested in agile's agility. They want their design-build-test teams and their program teams to be able to make and meet commitments so they can make appropriate capacity constrained commitments across the portfolio and to external stakeholders.

Agile Health Metrics for Predictability was perhaps my most popular post on LeadingAgile's blog.

In Bottom-Up Implementation & Top-Down Intent, I discuss my recommended approach to agile transformations.

Related to that, I wrote a post arguing that you should fix your Structure 1st: Why You Should Not Start With Practices

Part of your structure involves your design-build-test teams, also known as your Scrum teams. In Use Feature Teams. Yes, Use Component Teams I explaining these approaches and why I recommend using both.

What do Scrum teams do during the Release Sprint? Good question. This post has the answer. In short, many things, but not developing code that can't be tested immediately.

Oh, I also published an article in Agile Journal entitled Identifying and Improving Bad User Stories along with my friend and co-author Chuck Suscheck. We put another article up on sticky-minds: The Problems with Overachievers on Agile Teams.

January 15, 2014

What's DOING in Personal Kanban?

What do you do with Stories on your Personal Kanban that you are going to put aside for a day or three?

I'm committed to limiting my Work In Process (WIP) and to "stop starting / start finishing" but some stories/tasks just need to be put aside. I'm not talking about tasks that are blocked, waiting on someone else. Those I'll either flag or move to a Waiting/Blocked column. Rather, this post is about stuff that I need to stew on or need to come back to when my mind is ready. What do you do with those? Herein I'll tell you what I do, but I'm really interested in what you do. Please post your thoughts and ideas in the comments.

I don't have a HOLD column on my personal kanban wall. Hold seems to be a misnomer for me. It's a kind of lie. The work really still is in progress. It's WIP. I'm going to come back to it this week, maybe tomorrow, maybe even today. It ain't done.

I could split my task or story each time I feel the need to set one aside, putting part of it in DONE and part of it back in a ready column, but I kind of like my definition of what is a story, what is a task and what is a next-action (or sub-task). I don't want to monkey with that. Anyway, splitting stories is a kanban hazard.


For the following discussion you need to understand my context:
I have Projects (held in a folder) that get broken down into multiple Stories, each Story on its own stickie. Some Stories are stand-alone, not related to any Project.

I also have some Stories that have multiple "next-actions" (or tasks or sub-tasks, whatever you choose to call them). In the spirit of Getting Things Done (GTD), I note the next-action, or next several actions, on the Story stickie. Often, each one of these next-actions might take 5 minutes or less, so they don't seem to be a Story deserving of a stickie of their own.

So here's what I do for those tasks in that nebulous state of not done but not active either. I'd love for you to add your thoughts in the comments.


Some of my to-dos need time to stew, such as writing a blog post. I have lots of outlines and rough drafts. I create drafts quickly when the idea comes to me. Such activity never enters my personal kanban. In the spirit of GTD, if it takes less than a couple minutes to do, just do it. I very rarely create a Task or Story for such activity.

But when I select a draft blog post to finish, I put the blog-post Story on my personal kanban in DOING and leave it there until I'm done-done. But I won't finish it in one setting. I'll flesh it out and let it sit. I'll come back to it, pretty it up, put in some links and gather some photos, and let it sit. I'll proof read and polish it and paste it into blogger, and let it sit. I'll come back to it some morning to be sure it's ready to go, publish it, and tweet it. During all of that, I might add a next-action (sub-task) either into my draft blog post (such as "--insert photo here--") or onto the stickie (such as "trim the photos").

I'm pretty satisfied with how I do that.


Other times I'll have a to-do that I want to work on a little each day, such as practicing a coding kata or revising/rehearsing a short speech. Maybe I'll put a "next action" (sub-task) for each day of the week on the stickie and check them off as I go.

I don't usually leave those in DOING for the week. If I've done it for today, I don't like leaving it in the DOING column. I usually move them back to some ready column each day. But it's still in progress for the week.

I'm not completely satisfied with how I do that. Sometimes I've left such a story in DOING.

What do you think about this? Do me a favor and post your thoughts in the comments before you go.

June 10, 2013

Spike Solutions

I like James Shore's explanation of Spike Solutions. His focus seems to be on very short impromptu experiments (on the order of minutes). One thing about spikes that could use some more words are larger spikes. Sometimes I need to figure something out that may take more than a day. An example might be to experiment with one particular API for some new service I need to consume.

I recommend each team come to agreement on what's an acceptable maximum size for a spike. I recommend a day, or maybe two. If it will take more time than that, split it, just like you would for a story. Spikes need to have a clear acceptance criteria, a very specific question to answer. When the time-box is over, share the results with the team.

Often, such larger spikes are related to a user story and typically must be resolved before the story can be estimated. But for the spikes themselves, I recommend NOT estimating them. We want velocity to represent value added stories -- we want to measure the rate at which we add value. Either way, when using your velocity, when making release plans, you must understand your system and take into consideration when and how you come up with spikes and when you solve them. Do you find them late? Do you know about them but implement them late? If so, that represents unknown schedule risk.

I used to say that a consistent stream of day-sized spikes is good, but when I said that I would often forget to explain my context and assumptions. Having a continuous stream of new spikes that you solve almost as you create them makes sense if you are also doing continuous planning (without batching into large releases or without release commitments). Solving small spikes regularly keeps this activity from making velocity unstable.

Conversely, if you batch requirements into releases greater than, say, a couple months and if your organization is making release commitments, then in that case spikes represent risk in your backlog. Might want to knock out all spikes for the release right off the bat.


Wow, this is just my first post this year. I've been very busy with my LeadingAgile clients. It's time to get back to my writing!