processagileextreme-programminguser-stories

User Stories - Problems that can't be made user stories


I am from an XP background. I know the process very well and have solid working experience with it. I have found it to be the best way to develop software.

I find myself in the position of a process doctor of sorts and this creates much self examination and revaluation of my own understandings.

A very common thing I hear is that some work can’t be made into stories. I personally don’t believe this. The excuses include

  1. Its too big (The developer will have nothing to show until the end of 5 weeks).
  2. it’s a complicated algorithm or abstract concept (will take 5 weeks to write and nothing to show).

This question is to get hints, tips or suggestions.

I am looking for hints, tips, and suggestions as to how to address these and similar perceived problems (and more if you can think of them).

I will mark the answer that has the most information on how to get around users/developers who wont write stories and address their many excuses as to why not (I have only listed a few and there are many more).


Solution

  • So basically, your question is "What can I do if people claim a task is too big for a user story, and can't be split up.

    In my experience, almost any problem can be split up. Ask them if they can implement a simplified version, leave out advanced features, maybe even use default values in some places; basically anything to produce something that gives meaningful (i.e. testable) results within one iteration.

    Remember: The point of an iteration is not to deliver complete functionality, but just useful and testable functionality.

    This splitting can be difficult, but it forces you to consider what you really need first, which is very valuable. The developers may bitch about it (I often do myself :-)), but it's really necessary. Breaking down big tasks into manageable user stories is at the very heart of all agile methods.

    That said, if the task really, really, really cannot be broken down (think complex mathematical algorithm in a research setting, that takes weeks to even understand the basics of), then your iteration is too short. The iteration needs to be long enough to produce meaningful results. And if most of your problems are so hard that they take 2-3 months to get anything done, then that's your iteration length. But I've never seen a project where that was really the case...