February 26, 2015
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
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
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.
- 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
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.
April 8, 2014
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
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.
PROJECTS, STORIES, TASKS, NEXT-ACTIONS & SUB-TASKS
For the following discussion you need to understand my context:
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.
I'm pretty satisfied with how I do that.
IT'S DONE FOR TODAY AND A TODO FOR TOMORROW
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
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!
November 15, 2012
Here are the sketchnotes from my November Agile Immersion workshop.
These sketchnotes were done by a business partner of mine, Jenny Trautman of evenview. Sketchnotes aren't the main thing evenview does -- sketchnotes are an artifact. What evenview does is help people bring innovative strategies into focus. They lead fun, high-energy meetings using interactive visuals that draw a team together. With their support, groups collaborate to develop a shared vision, create a plan for action, and implement their ideas. Use them for your next strategy meeting or kickoff.
By the way, this workshop is designed for everyone. No agile experience or programming skills required. All types of roles have found it benefical: product managers, marketers, managers, office managers, business development executives, developers, testers, CFOs, and etc. Check out this interesting blog post from a recent non-developer attendee.
October 29, 2012
At the end of each week I do a quick retrospective on my use of Personal Kanban, the tasks I've completed, and the week in general. I don't do anything elaborate or time consuming. Just a simple evaluation of how I'm doing.
I use two particular approaches to my personal kanban retrospectives more than any other.
+s and Δs
Most Successful / Least Successful
I'll take notes, again on an index card, on these high points and low points.
Not a Commitment
What I don't do is compare my actual achievement against a plan. I do "plan" my week, but it's not a commitment to specific tasks. It's more of a re-prioritizing of the backlog and preparation for the days ahead. I use that time to make sure I don't miss any commitments or fail to prepare appropriately.
I hope you found this useful. What kind of Personal Kanban Retrospectives do you do?
Register now for my 11/5/12 Agile Immersion Workshop. This low cost day-long hands-on workshop will guide you through an agile project, from inception through the first couple iterations. Through this immersion, you'll understand agile 1st hand. Lunch is included.
October 24, 2012
Not long ago I wrote about some changes I made to my personal kanban. Today I'm writing about why I do this. Much has been written about the benefits of using Personal Kanban and Getting Things Done (GTD) so I'm going to stick to what I personally get out of it.
I get uneasy when I have lots of unfinished projects around the house, half-read books languishing, things I've started and have forgotten about. ADD runs in the family so I'm likely an undiagnosed sufferer. When I rediscover something I once thought was important and have since forgotten, I remember why I thought it was important and feel bad for having not finished it. I feel stressed about needing to put one thing aside and finish the newly rediscovered badger. It's a little stressful. Not "I can't take it anymore!" stressful. Just a nagging background stress. There are plenty of stressors in my life so I don't want to add more if I can help it. And I can help it.
When I first started using them, GTD and Personal Kanban made matters worse. And better. It made me feel worse because now everything is visible -- all the half finished projects and incomplete initiatives. Yet it made me feel better, knowing that I won't forget anything. It also helped me prioritize my work explicitly and stick with that prioritization for as long as that prioritization made sense. My kanban helps me remember why things are in the state they are in, being intentional about what I choose to do.
After a while, GTD and kanban helped me reduce the backlog of partially completed work. It helps me focus on work already started. It helps me not start new activities that are of equal or lower priority -- or things that have a lower Cost of Delay. Seeing how much I have in process helps me to stop starting new work and to start finishing what I've already got going on.
I also discovered how much longer it takes me to finish tasks than I thought. Oh, yeah, "blog post"; I'll just typety type, a little proof reading, maybe a picture and I'll be done in half an hour. Heh. No, not really. Takes me a bit longer than that for the type of posts I do and the care I put into them. And there are all the other things: tweet it, email it to the person who requested I write about it, put a notice about it on some appropriate LinkedIn group, get interrupted for dinner, go to an Agile Atlanta meetup, decide to finish it tomorrow after work, and ultimately edit this post again because I thought of something else that should go in, like this paragraph. Anyway, kanban helps me understand that I'm an overly optimistic estimator. Understanding that helps me put stuff in the backlog instead of just starting it.
Now I feel much better. Sure, there are new things that come along that are Important, Urgent or have a High Cost of Delay, and I'll increase my WIP for a while. And that can be stressful. But it's a different kind of stress. No more is it "I have all this work and it's out of control". Now it's "I have some important work to do, but I know what it is, what state it's in, where it is stored, when it's due, and I feel in control." I still have a lot I want to do. But I'm in control.