Today we had our iteration planning meeting. It was a long one as we’re trying to sharpen our user story technique and are switching estimation methodologies from hours to “story points” or “NUTs” (back to them). We managed to wrangle some ill-defined stories into the standard format that Dan North talks about, define acceptance criteria or scenarios, and poker planning our estimates. Long but productive and engaging which counts as a win in my book and personal experience with meetings in general. Great.
What came up in the course of our planning were a couple of items that are clearly technical aspects. They don’t fit into the story mold, at least not intuitively, immediately or even under a reasonable level scrutiny. I like the term Scott Bellware used once to describe this kind of thing: aspects. The subject came up on a discussion list we’re both on and, for whatever reason, I clung on to it and have been mulling it over these past few days. I was aware of the idea of an aspect from aspect oriented programming as a cross-cutting concern that affects more than one place in your system, something that’s essential to operation but orthogonal to your business logic. The canonical example is auditing or method-level security.
Sometimes, though, aspects surface as work. In this light I think of them as the bastard half-siblings user stories. An aspect in the backlog sense bares some (though not complete) resemblance to an AOP aspect. They’re cross cutting concerns that touch a number of areas in a system but aren’t specifically business logic. More accurately they are tangential to your domain logic. Some people call them “non-functional requirements” I suppose, but I like the term aspect; it’s lest Dilbert-ish and conserves syllables (unlike this post, ahem).
Danger! This reeks of big design up-front, doesn’t it? Further, I’ll point out that a backlog with a lot of aspects is probably a smell (or people anti-pattern) indicating a few possible issues. Maybe you’re work isn’t being captured by customers or a customer proxy (business analyst, etc.) in business specific-terms. That’ll keep you off the Agile path for sure. How do you know you’re delivering working software in the customer’s terms when it isn’t specified on their terms? Make no mistakes: an aspect might be driven by customer pain but 90% of the time it’ll be the developer that surfaces it into the backlog. So, yeah, danger.
There are a couple of tips for dealing with aspects:
1) Recognize when something is really a story masquerading as a cross-cutting concern. Often times you can turn an aspect into a scenario for a story. Sometimes, too, you really need a story to drive the aspect and to focus you in on delivering business/product value. Look to the stories first. If nothing leaps out as a home for the aspect consider whether or not you really need it. Express business value as the side-effects experienced as a result of adding the non-functional requirement (for example: increased speed) and bring that to the user for priority just like stories. If it passes the ROI test (see 3 below) then maybe it’s time to let it go and move on with our life.
2) Keep aspects super tiny and specific. Expand the scope and reach of an aspect over time in an evolutionary, continuous design manner rather than all-at-once. When you’re adding stuff that smacks of framework or re-use tread carefully because you could be asking for either a swirling vortex of anti-productivity or unusably restrictive software. Find an example or three where you can use this functionality and, in your current iteration, make done speaking to those one or two examples with the idea that you’ll revisit the issue when you have a bit more education. This leads us back to is the aspect really a scenario or acceptance criteria for a given story in which case put it on that story and be done with it.
3) Realize that aspects are risky like investments. You should be able to calculate the ROI of injecting a cross cutting concern into the application and you should be held to that claim. This will have the effect of keeping things small and also help with the visibility factor. There’s no way a stakeholder or user will understand “create a simple caching mechanism” but they will understand: “Dear User, This will speed us up by enabling automatic refresh in these several areas, Love, Dave.” At all costs try to keep your investments in the micro-loan category and be sure you can (and do) justify them to the money and audience.
I’d love to hear other people’s thoughts, experiences, and/or criticisms on this subject. Am I being indulgent? Hmm… let’s see who I’ll rile up here.