9
  1. Given a small team (3 people or so) and a technically challenging area (e.g. middleware, embedded software etc.), and
  2. Assuming that a user story is a smallest thing that has value for the end user,

how do you go about handling stories that take more than one month to reach the DONE-DONE state? Of course one could always split them into several so called "technical stories", but they are, with the exception of refactoring spikes, a big no-no in Agile, aren't they?

16

First, do things which do make sense. If it does make sense to split the big story into a few smaller ones, even if you can't deliver those parts to your client separately, why shouldn't you do it? You don't get paid for being perfectly adjusted to what some thought-leaders say.

Second, if the situation is rather an exception treat is like one. If you don't want to split the story into smaller chunks you may push one story among a couple of iterations and agree that this time it will just look like this.

Third, if the situation is rather common think how you can adjust process you follow in a way which actually allows such stories. One thing which comes to my mind is Kanban, where you resign from iterations completely and you can deal with one XXL story and at the same time build a lot of smaller ones as you don't limit work basing on time but you limit a number of concurrent tasks. In this case one huge story would take only one slot but it would use it for a longer time.

Four, don't be orthodox on delivering value to a client. If you wanted, and needed, to do some housekeeping in architecture which brought exactly 0 value to your customers, but helped you to limit maintenance costs would you reject such task? Probably no. And yet you would somehow put it in your backlog.

After all agile is about flexibility, about reacting to changes and not about keep rules at all possible cost, right?

  • 1
    Love the comment "You don't get paid for being perfectly adjusted to what some thought-leaders say". – Ken Clyne May 18 '11 at 17:24
  • 1
    One thing that always makes me think - isn't refactoring really bringing value to the customer in the long run too? Especially if it reduced maintnance then it must have changed "something" - either allow you to deliver more items in the future (a customer +) or reduce the amount and/or criticality of defects (also a customer+) - so maybe it's not as bad as we sometimes think? :) – RnR Jun 6 '11 at 12:37
  • Well, it probably does. At least as long as it is done well. However it is hard to draw a direct line from refactoring of a piece of code and client's gain. Besides, I doubt many clients would pay for "refactoring feature" :) – Pawel Brodzinski Jun 6 '11 at 13:27
6

Clinging to user stories as the smallest planning unit is one of the abhorrent errors held by agilists.

What's the user story for a bridge? Where is the construction of piers, spans, beams, etc. that make up the substructure taken into account? The construction of the deck (roadway) is of such minor consequence (relatively speaking), in this narrative it isn't even detailed.

How many user stories for a house involve the foundation and the roof? Yet they are the most expensive parts of a building.

User stories are a fundamental tool for scope definition and goal setting for the project but they are not the only tool to use. They help define the purpose for a project and when it is complete. They do not provide the entire scope of the effort involved. They help begin the planning process. They are not the final plan.

  • 2
    I really hate the bridge analogy. You can't really release a subset of a bridge in the same was as we can in software. – Ben Jun 6 '11 at 10:57
  • 2
    No, you cannot release a subset of a user story. That's my point. When the infrastructure to enable some functionality isn't present it needs to be developed. A user story encapsulates value provided to the user/PO. If the user story fits on a card, but the development needed to implement it requires more than one (such as the 30-day sprint as posed by the OP), then user stories are inadequate for planning/scheduling. – Huperniketes Jun 8 '11 at 2:46
  • 1
    But you can break users stories up further than smallest value to customer. In fact, the last 6 months, I've been working on a project where the entire point is for customers to notice no difference (platform migration). I could tenuously phrase a user story with the value of making future changes more rapidly but that wouldn't be achieved until the entire project is done (in fact, during the migration we actually make our platform harder to work on). – Ben Jun 8 '11 at 14:31
  • 1
    Our stories then don't focus on the value to the customer, or even to the business, they're testable steps that take us closer to our goal. This is what Pawel is talking about (don't be orthodox on delivering value to a client) in his answer. – Ben Jun 8 '11 at 14:34
  • 1
    Anything smaller than value to the customer isn't a user story, which is the point. Call it a developer story. But the OP, as do many agilists, tried to shoehorn everything into user story because that's what agilists like to use to keep development agile. Breaking it down further risks creating a BDUF. But quite often, breaking it down is a necessity. Hence, don't limit development planning/scheduling nor agile buzzwords to user stories. – Huperniketes Jun 8 '11 at 16:01
5

If you genuinely can't split the story into valuable chunks, I'd go with "smallest testable component" to slice it up.

Can you give an example of a story?

  • I have to be quite generic for NDA reasons, so an example would be "To calibrate a sensor of a medical device by adjusting a number of parameters. Parameters are interdependent so implementing a support for just one parameter does not provide any value to the end user." Implementation constraints: C++ as the language, embedded environment and necessity to deal with an already developed framework that cannot be practically changed due to re-testing costs incurred by applicable regulatory compliance. Which, in turn, leads to extra effort for finding workarounds. – DmytroL May 18 '11 at 12:46
  • I like the idea of "smallest testable component", though. – DmytroL May 18 '11 at 12:51
  • 1
    I use "something that's small enough to get feedback on quickly", since that's mostly why we do Agile in the first place. If a team is productive enough to produce a whole feature in a sprint - or between relevant stakeholders' availability for providing feedback, with whatever cadence that is - then I don't recommend splitting the story. – Lunivore Jun 6 '11 at 9:39
1

Great answer from Pawel. Some other things to consider:

Done should be from the perspective of who the story is getting delivered to. This is not alway the end-user.

There is a difference between potentially-shippable and shippable. The work that we do we try to be feature complete although it may not be feature-set complete.

All stories can be broken down. It is difficult to do this theoretically during planning.

Try not to break stories down across the process dimension. For example, don't build in one iteration and test in the next. This will impact throughput and can lead to technical debt.

  • Thanks, this actually seconds the "smallest testable component" approach suggested by Ben. – DmytroL May 19 '11 at 10:29
1

Ken had some good advice. We have found that the most important things to keep in mind are that...

  1. The code should always be potentially shippable. If there were a huge bug found today that took the entire application down, could you stop, fix the bug, and push to production? It may mean there are some partially completed feature sets, but what everything that is there is high quality, tested, and complete.
  2. You must have made demonstrable progress at the end of the sprint. This is important when thinking of how to break the item down. So maybe this piece by iteself does not provide "value" to the customer, but we can demonstrate this piece to the customer and use that to show progress towards the end goal. As Ken suggests, definitely avoid splitting at process lines (develop then test) at all costs. So it helps to think that a story must either provide value, or demonstrate progress towards providing value.
0

The same way you tackle any epic: break it down into smaller chunks.

There are many different ways to do this. For example, if your project has lots of other (legacy) systems to interact with, try to find a lower-level user story that deals with ONE legacy system. And see how implementation of that impacts the overall epic story.

Another approach is to tackle things from a stakeholder viewpoint.

Check out this post for yet another way to deal with it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.