Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Stories and Aspects

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.

This entry was posted in Agile, aspects, BDD, requirements, Scrum, stories, user stories, XP. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

2 Responses to Stories and Aspects

  1. Joe Ocampo says:

    Interesting topic. I had never heard if technical stories being refered to as “Aspects” but I will go with it.

    When approaching system or technical oriented stories there are several approaches I recommend.

    I have extended the story template that Dan North uses to include additional context.

    As a {Role} I want {feature/functionality] so that {business value}
    Benefit: {What are the benefits of doing this?]
    Detriment: {What if I don’t do this?}
    Unit Estimate:{1-20}

    As a {developer} I want {to create an logging instrumentation framework} so that {I can have a central point to configure logging and blah blah blah.}

    Benefit: Decreases maintenance cycles and allows for easier debugging saving around 50-70% in man hours per trouble ticket.

    Detriment: Logging will have to be ad hoc and will not be as full featured increasing remedy time on production issues.

    Unit Estimate: 5 Units

    It is important to remember that the System under development or a developer can assume the role within the story context. The important aspect of this type of story is buisness value coupled with technical debt awareness.

    I can’t remember which book I got this idea from but sometimes the request is a little more nebulous. We refer to these nebulous request as Guiding Principles [GP]s.

    The user interfaces of the application should allow for an entry level technician to understand the interaction heuristics with minimal training.

    Nebulous and subjective in nature, yes. But can I easily use the GP as a talking point when the business decides to come up with some crazy UI design. Oh yeah!

    Hope this helps.

  2. I’m very curious to see (a) who you rile up and (b) what comes of this discussion. I work in health care information technology, and the two very things you mentioned, auditing and method-level authorization, are very serious concerns in health care applications that deal with PHI (protected health information). Yes, things like this reek of infrastructure and inflexibility, and they are part of every new feature. In a widely deployed application, bad choices can have long-running consequences when refactoring the entire application is not feasible.

    Let the games begin!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>