I’m just beginner but i wrote some thoughts about my approch to agile granulation (very amateur approch) to improve some planning steps & DoD definition:
http://molboro.blogspot.com/2011/04/user-stories-tasks-agile-tasks.html
i would like to hear some thoughts from more experienced people.

A couple of key points before I can address this:

a) I’m reluctant to call something of this magnitude a refactoring.
b) I never talk about “value points” which I’m assuming is the value of a story or small feature.

Especially given those points, I don’t see any reason at all to estimate this new feature as anything but 20 points. I would probably have a conversation with my product along the lines of “This new feature is in the middle of some ugly code that has just degraded over the years, especially back when we rushed a few changes in a year ago. So we have two choices in how we implement the feature. The first option is for us to fix up that ugly mess while we’re in there. We’ve estimated that at 20 story points. The second option would be to find a way to slam this feature into the middle of the ugly code. That’s probably 8 points. Now before you jump at the 8 point option, let me explain something. Every time we go into this code as it sits today, things take a little longer than we all wish. For example, if we’d fixed this code already, I’d probably tell you that adding this new feature would be 5 points. That is–almost half of the 8 I’m telling you it is now. The difference, those three points–come from having to add this into the fragile code we have today. If we’re going to be back in this code much–and you’re the best judge of that, Mr. Product Owner–we really need to bite the bullet and fix this code now before things get worse.”

thank you for this helpful blog posting.

There is one question in my mind to which I did not find an answer up to now:
How to count the effort of larger refactorings, i.e. at the order of several person months?

The background:
We’re working on a software which consists of legacy-code from the pre-Scrum era.

The team was asked to estimate a new feature.

They returned: if the Product Owner wanted them to add it in a former,
so called spaghetti style, then it would be 5 Story Points.

On the other hand, when implementing according to their new insight
and use the new structured architecture,
the feature would estimate to 20 or 40 Story Points.

In both cases the same functionality is delivered to the customer.

Several solutions came to my mind. Which one would you prefer?
Or do you have another suggestion?

a) Do not count for refactorings – even not for larger ones.
b) Do count for refactorings – since they belong to daily-business.
c) Introduce a second measure: value.

Using solution a) the mentioned feature would be at 5 SP .
Using solution b) it would be a e.g. 20 SP feature.
Using soution c) it would estimate to 5 Value Points but 20 Story (effort) Points.

I tend to use solution c). But, it has a drawback since implies that effort for adding new functionality in Story Points is proportional to business value.

Thanks again for the help, keep up the great work.

First, I’d treat that as a non-functional requirement. Non-functionals can also be written as user stories. I’d write the one you suggest as something like “As someone whose language includes extended characters, I can enter such characters in all fields of the system.” If there are a lot of those fields, I’d consider this story to be an “epic,” meaning simply that it’s a big ‘un. I’d then break it down into parts that fit within our sprints: “As someone whose language includes extended characters, I can enter such characters on all of the admin screens” and “As someone whose language includes extended characters, I can enter such characters throughout the order processing workflow.”

I need to blog for November. I’ll try to do so on the subject of non-functional requirements so stay tuned for that as a new posting, probably the week of 10 November 2008.

Let’s say I need support for international characters as part of a project with several front-end changes spanning multiple sprints. Pretend I need to do a fair number of complex database migrations to support international characters (pretend our database doesn’t support changing column types). If these migrations will take up to 4 weeks, including testing and moving to production, and we’re doing 2 week sprints, should I consider this one large story, with the Role being the “System” or something along those lines? Or, of I can break it into several pieces, should I still call them “stories”, or just forget the agile methodology for a few weeks and manage the project with tasks?

I’m trying to formulate an exact description that captures my view of what goes in the sprint backlog. I think it’s this: The sprint backlog contains all plannable work of any consequence that is not best reflected as work that repeats from sprint to sprint.

So by that I mean that the sprint backlog:

• contains only the work we can plan. If we don’t know about something, it obviously can’t be on the sprint backlog (until and unless we discover it mid-sprint, in which case it’s added)
• does not trivial work items. So five-minute tasks aren’t on the backlog. So normally I wouldn’t expect “check code into Subversion” to be a task. That is best considered just a part of whatever coding task(s) are there for a product backlog item. (If the team is not in the habit of checking code in, I may have them explicitly put this task in for awhile until it becomes a habit.)
• does not contain items that repeat from sprint to sprint. The daily standup or daily scrum would fall into this category. I don’t want to see 10 or 20 tasks saying “go to daily scrum.” We all know that happens, it’s just part of what I lump as “corporate overhead.”

So, to your specific question: If your team has a understanding that when there’s a bit of time, you spend it refactoring then I would not put up tasks for that. But if you have plans to spend a full day refactoring as a pair one tough class, I would put a task for that.

Here’s a sanity test I use: The number of hours planned into a sprint should be relatively stable from sprint to sprint. (This is known as the team’s capacity.) If you agree to do a big refactoring (16 hours, say) in one sprint but don’t put tasks up for it, it will look as though the team’s capacity was lower that sprint. I don’t care how this looks to management; this number should be of no interest to them. (They are interested in velocity.) But the team uses capacity to plan each new sprint: if the team finished all planned work last time, perhaps the number of hours they can commit to next time should go up a few. Leaving a big refactoring out of the sprint backlog would make this very difficult.

Nice articles, it really helps me in solving some problems I encounter in my first Agile Experiences.

I have still one question regarding non-story tasks.
Do we estimate tasks that are used to resolve technical debt? We sometimes feel the need at the end of a sprint to review some code and get some things right (architectural & technical). I don’t like to add a refactoring task to our task board since this is meant to be a continuous effort. I spend a lot of attention to code quality, since not every developer feels the same way about that, we often end up pairing a whole day to refactor the code.

I think the approach is suitable for any work that is a small percentage of an overall iteration and occurs at unpredictable frequency. Anything big and predictable (e.g., moving to Vista because my COTS partners require it) would be something I would treat as a full product backlog item / user story rather than lumping it into a Miscellaneous category.