There are many books and articles about creating user stories when using an agile development approach like Scrum, XP or Kanban. The standard techniques focus on technical content and process flows when dividing high-level stories into smaller and smaller chunks. This post approaches the topic from a different perspective — that of the business.
I hope we agree that small stories are better. They are easier to understand, simpler to implement, and reduce the project risk. That said, it can be difficult to break up large functional elements of the software into small stories.
As you go through the process of evaluating, prioritizing and dividing stories, here are some critical items to consider:
- Identify obstacles to splitting the stories and eliminate them. If the same excuses for not splitting stories keep coming up, deal with the excuses.
- Don’t get caught up in design issues. There is a tendency to want to keep the system design elegant. That’s fine but building temporary logic and interfaces is okay too.
- Seek out stories that produce results having business value. Don’t just focus on completing tasks and generating code.
There are many ways to approach stories.
Stories tend to evolve around the user interfaces, the business processes, and the data flows managed by the software. Those approaches are fine and you should also consider the following unconventional ways of compiling stories:
- Consider pre-delivery deadlines such as sales demos, trade shows and beta tests. These are often important revenue-generating events that will impact how you prioritize and implement stories.
- Divide by stakeholder needs, for example, sales and marketing before manufacturing. You may find it simpler to focus on the needs of a stakeholder group rather than trying to please everyone.
- Divide by target user attitude delivering to co-operative users first. If you find a user group or even a few individuals who are interesting in the software, target their needs first. You’ll get more and better feedback.
- Deliver within a limited geographic area to avoid time zone, date, currency, language and infrastructure issues. Geographic location can introduce many complexities to the development effort. Keep the distribution area small to start.
- Identify high-value user activities and deliver those sooner. The software is likely to have many features and functions. Work with the business organizations to find the high-value ones and focus on those first.
- Identify high-risk software elements and implement those first. It’s natural to work on the simple things first though it’s the complex ones that carry the greatest risk. Get those out of the way early in the development effort.
- Separate power-user or advanced features from standard ones. Software often has advanced features or configuration options. They can usually wait until later in the development cycle.
Breaking down user stories into manageable chunks is not easy. Hopefully, these approaches will give you some additional ideas. Do you have any ideas to add?