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.
A blog about product development, product management, team and program management, lean, agile, and software development. Occasional posts about bicycling, Christianity, or racism.
February 26, 2015
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.
Subscribe to:
Posts (Atom)