Resizing stories

April 10, 2007 — Posted by Al Shalloway

In our Agile Planning and Estimating with User Stories course I am often asked about when to resize stories. The short answer is to resize stories when it is apparent that their size has changed. Remember that the product owner prioritized the story on the backlog while considering the value return compared to its cost. If its cost changes, its priority may change as well. If you don't resize the story, then the developer, in essence, is making a prioritization. Typically, story sizes go up, not down, although that can happen. They typically go up because developers discover new things about the story. Sometimes these are how to build it, but sometimes they are really other features hidden in the original story. Let me tell you an embarrassing episode I personally did that illustrates this point.

Several years ago, before I was truly into Lean-Agile development, I had a client that I was somewhat supporting on the side. One day he "forced" me to implement a long awaited feature by just letting me know that the next Sunday, they were doing training on it! (This was the Monday before). Since the feature only was going to take about 6-8 hours, this wasn't as unreasonable as it sounded and I said fine. I figured I could start on Thursday, but, as you might guess, I didn't quite start then because things came up (who would have thought!). I started Friday afternoon! But no biggie, I had Saturday if needed. In fact, around noon Saturday, I had the feature well under control when I came across an error condition no one had thought of. The error had to do with credit card information being entered (I remember that much, but, honestly, don’t remember the details).

To handle this error condition properly would require me to pretty much remember where the user was, tell them about the error, let them leave the spot they were at and then restore them to the position the error occurred when they were ready to fix it. Now I remember thinking maybe I should run this by the customer (the owner of the business asking me to make the change), but I decided not to. Hey, I was a macho C++ programmer and could get things done right and handle the error. Besides, he was a Yankees fan and I was a Red Sox fan (the owner was a good friend of mine in spite of this lack of values on his part). The thought that perhaps handling the error might best be done by letting the user know of the error and then just forcing them to re-enter the information --- ohhhh so inelegant.

Anyway, I did get the new feature and the new error handling function in around 3 AM Sunday morning (uploaded via PC anywhere). I was so proud of myself, I could just hear the manager doing the training telling me what a great job I had done. I could hear my friend saying – “great job Alan” whereupon I would interrupt him with my story of how I included this unforeseen error handling as well in which he would be totally in awe of my abilities.

Sure enough, Sunday afternoon, the training went great and the manager heaped praise on me. Monday morning, my friend called, and as expected, he also heaped praise upon me. Whereupon, I said, “and hey, you know while doing this I came across this error condition”, expecting him to say something like – oh, that’s not good where upon I would tell him how I handled it and get even more praise. But his response was – “ah, if that happens, don’t worry about it, just let them re-enter the information!”
I was stunned. This option hadn’t ever occurred to me. I clearly wasted 6-8 hours of time by putting the error handling in. But that wasn’t the worst of it. In the year or so after this, the added complexity of this error handling caused about another 20 hours of work.

Now, how does this relate to re-sizing stories? When I saw there was an additional 6-8 hours of work involved, I would have asked myself, is this a resizing of my new story or can I treat it as a new story? In this case, I would treat it as a new story. But just sucking it in and doing the extra work is not a good option.

The need for re-sizing typically means we have a better understanding of what we need to do. This is to be expected and should not be considered to be a failure by the team. It should be greeted with “great, we have a better understanding of things.” Stories can be resized when it is discovered it will take more work to get what was originally planned, or new stories can be split out of existing stories when they are discovered to be embedded in the planned story.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban