user stories


Relieving Agile Tension: How to Write Small Stories That Still Have Value

There are two practical goals for user stories: Each story should be beneficial to the business, and each story should represent a small piece of work. However, there is tension between these rules, and they often push in opposite directions. This article discusses how to keep stories small and tasks manageable, while ensuring they retain business value.

Allan Kelly's picture Allan Kelly
The Three Amigos Strategy of Developing User Stories

Developing software correctly is a detail-oriented business. George Dinwiddie writes on how using the Three Amigos strategy can help you develop great user stories. Remember, the goal is to have the work done just in time for planning and development. It should be complete enough to avoid stoppages to build more understanding, but not so far in advance that the details get stale.

George Dinwiddie's picture George Dinwiddie
How Visualization Boards Can Benefit Your Team

While many teams can use help structuring their conversations, some teams also need some way to know whether the structured conversations that have taken place have provided sufficient information. Kent McDonald explains how using visualization boards can help in these situations.

Kent J. McDonald's picture Kent J. McDonald
Identifying and Improving Bad User Stories

A written user story is a very short narrative—a sentence or two—describing some small piece of functionality that has business value. User stories are intended to foster collaboration and communication, but writing these short narratives poorly can negate agile’s flexibility. Charles Suscheck and Andrew Fuqua explain some common failure patterns that will help you focus on the right role, value, and business functionality when writing stories.

Defining Requirement Types: Traditional vs. Use Cases vs. User Stories

If you have recently transitioned to an agile team, you may have questions about the differences between user stories and use cases, especially how they differ from tradition requirements writing. In this article, Charles Suscheck defines each of these requirements types and uses a running example to illustrate how they differ in a real-world setting.

Charles Suscheck's picture Charles Suscheck
Stop the Wishful Thinking: Software Estimation Reality Check

Daryl Kulak tackles the most common beliefs in software development regarding estimating, and shows us ways and methods to help developers deal with the demands of businesspeople.

Daryl  Kulak's picture Daryl Kulak
Helping the Customer Stick to the Purpose of a User Story

Lisa Crispin writes that you need to understand the purpose of a user story or feature. Start with the "why." You can worry later about the "how." The customers get to decide on the business value to be delivered. They generally aren't qualified to dictate the technical implementation of that functionality. It's up to the technical team to decide the best way to deliver the desired feature through the software.

Lisa Crispin's picture Lisa Crispin
Edit Those Epics

It can be tricky for managers and technical leaders to make the transition to agile. They’re likely accustomed to doing things a particular way. What’s more, they may try to squeeze their old ways into the new, agile approach. Here, Johanna Rothman describes why that isn’t a good idea, especially regarding stories that are too big.

Johanna Rothman's picture Johanna Rothman
Write a Blockbuster Using User Scenarios

Big projects require many little user stories. But if these scenarios don't add up to one good story, then you're probably missing out on the big picture. In this week's column, Jeff Patton describes how his team weaves many small tales into a single strong report by identifying key characters and themes.

Jeff Patton's picture Jeff Patton

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.