We are currently struggling with how to integrate work on refactoring/simplifying/cleaning our product codebase with existing streams of stories and bugs. One of the tricky aspects of this is how to estimate and prioritise the cleanup work: how much is it worth, and how much time should we spend on it this iteration?
Martin Fowler has written about extending the idea of “technical debt” by including the concept of “interest”. Extra time spent on completing any given task compared with the time which would/might have been spent implementing that outcome on a cleaner system is effectively an “interest payment” on the “technical debt”. Noting an estimate of such an amount along with the elapsed time on each piece of work allows a relatively simple calculation of the total “interest payments”, and helps inform any decision to “pay off” the debt by refactoring, simplification, etc.
MF Bliki: EstimatedInterest
In my work as a software developer I mostly encounter stories in the form of “user stories” - a way of communicating about a change or new feature by describing it as a story. In the wider world, and in the other things I do with my life, stories play a much larger part. Stories form the basis of a large part of human communication and empower everything from watercooler gossip, through books and newspapers, to TV and games.
Stories seem a large part of our lives, and of the lives of everyone.
elearnspace: The Secrets of Storytelling: Why We Love a Good Yarn
The Secrets of Storytelling: Why We Love a Good Yarn: Scientific American
Mike Cohn raises an interesting and topical issue about how to indicate what you are working on at a daily stand-up meeting.
In our project we are currently working on an iteration where all the stories overlap and interact. Our usual approach is that each developer grabs a story and works on it until its done, then repeats until either the iteration ends or we run out of scheduled stories. In this case we need something a little smarter - some way of grouping the tasks for the iteration, regardless of which stories they “belong” to, so that developers can work on a chunk of related functionality rather than a story as such.
This is potentially risky, as some of the commenters on the above post point out, but at the moment I can’t see a way around the problem.
Should the Daily Standup Be Person-by-Person or Story-by-Story? | Mike Cohn’s Blog - Succeeding With Agile™
Back to thinking about stories in the agile software development sense.
For the first time this iteration we have reached a situation where two stories were left incomplete at the end of the iteration. I could give a bunch of excuses about changing priorities during the iteration, but the point is that agile processes are supposed to be able to cope with this kind of stuff.
So now we are at the point of deciding what to do with these stories. Luckily, the guys at Elegant Code are also facing this problem, and discuss some options in a recent blog post.
Elegant Code » What to Do with Left Over Stories
In our case, the discussion is still proceeding. From an agile purity point of view the suggested approach of throwing the part-completed stories back into the pot for re-estimation, re-prioritisation, and re-scheduling is certainly compelling.
This time on the topics of storytelling in presentations
Storytelling 101
and in the context of “web 2.0″
50 Web 2.0 Ways To Tell a Story
At the moment, the company I work for is pressing forward on implementing an end-to-end agile approach to software production. With this in mind, I was intrigued to see an interview with someone who runs a company offering consulting and training in just this area, which they refer to as “industrial XP”. I found plenty of thought-provoking ideas in there.
InfoQ: Joshua Kerievsky about Industrial XP
The discipline of writing good user stories - ones which communicate clearly to all appropriate stakeholders, give enough information for effective discussion, yet leave enough freedom for innovative solutions - is surprisingly tough. Writing such stories for integration tasks is harder still. Shaun Jayaraj has some thoughts:
What to do? we are like this only: User stories in the Enterprise Integration space
Constructing sensible and effective user stories is a vital and sometimes surprisingly tricky part of XP-style agile software development. There are plenty of ways to choose a less than optimal story breakdown.
Lasse Koskela has put together a thoughtful blog post about this topic.
Lasse’s weblog - Ways to split user stories
One fairly familiar way of writing requirement stories is “as a … I want … so that …”. Elizabeth Keough reckons this is not quite right.
sirenian: RIP As a… I want… So that…