In agile development, a bloated backlog results from teams accumulating huge lists of requirements, usually in the form of user stories. Retaining every possible story for building the product weighs down the backlog while squeezing (or obscuring) the highest-value stories. The best way to help minimize this risk is to optimize the time spent defining and refining the product priorities.
Writing independent user stories seems simple, but it is actually difficult to do well. There are often parts of some stories that are dependent on other stories' functionalities, so it's not easy to keep them separated. Kris Hatcher relates how his team wrote and scored stories to keep them independent but still meeting acceptance criteria.
You can use analytical methods to assign business value to a user story, of course, but another way is simple estimation. Allan Kelly describes an estimation exercise that combines the Scrum tool of planning poker with a TV show format to add some fun. You end up with enlightening conversation and revealed requirements.
Allan Kelly says that ideally, companies should put a dollar amount on each planned business decision. But pinning down financial value can be hard, and besides, there are many other factors to consider, such as sustainability and customer service. He looks at various ways to assess the business value of user stories.
Acceptance test-driven development (ATDD) means different things to different people based on their experiences—from "It's all about testing" to "It has nothing to do with testing,” and from "TDD, ATDD—it's all the same" to "TDD and ATDD are nothing alike." These nine landmarks will help you navigate ATDD no matter where you are coming from.
Drawing on real events from the authors' combined experience, this story picks up where it left off in the November 2007 issue and follows a fictional team as it encounters some of the pitfalls of using test-driven development.