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?
A blog about product development, product management, team and program management, lean, agile, and software development. Occasional posts about bicycling, Christianity, or racism.
October 16, 2015
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.
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.
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:
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.
January 20, 2015
Airplane Etiquette: 12 Rants
How about a little airplane etiquette? 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.
Bonus:
Bring an orange. Eat it on the plane. The smell of citrus is most often welcome on a flight.
# 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.
Bonus:
Bring an orange. Eat it on the plane. The smell of citrus is most often welcome on a flight.
Subscribe to:
Posts (Atom)