Software development magazine: UML, Agile, programming, testing, Click here to view the complete list of archived articles This article was originally published in the Summer 2008 issue of Methods & Tools Acceptance TDD Explained Lasse Koskela This article is based on a chapter from the book "Practical TDD and Acceptance TDD for Java Developers", published in October 2007. It is being reproduced here by permission from Manning Publications. In the spacecraft business no design can survive the review process, without first answering the question—how are we going to test this thing?
—Glen B. In the previous chapters, we have explored the developer-oriented practice of test-driven development, covering the fundamental process itself as well as a host of techniques for employing TDD on a variety of Java technologies. TDD helps software developers produce working, high-quality code that’s maintainable and, most of all, reliable. Acceptance test-driven development as a name sounds similar to test-driven development, doesn’t it? All About Agile: How To Implement Scrum In 10 Easy Steps. Introduction to User Stories. 1.
Introduction to User Stories A good way to think about a user story is that it is a reminder to have a conversation with your customer (in XP, project stakeholders are called customers), which is another way to say it's a reminder to do some just-in-time analysis. In short, user stories are very slim and high-level requirements artifacts. 2. As you can see in Figure 1 user stories are small, much smaller than other usage requirement artifacts such as use cases or usage scenarios. Figure 1. Important considerations for writing user stories: Stakeholders write user stories. Figure 2. 2. Figure 3. 4. There are two areas where user stories affect the planning process on agile projects: Scheduling. Figure 4. 5. As you can see in the Disciplined Agile Delivery (DAD) life cycle of Figure 5, there are several distinct "phases" or seasons in the life cycle (some people will refer to the agile delivery life cycle as a release rhythm).
Inception. Figure 5. Figure 6. 6. Figure 7. 7. 8. Agile Software Development: Writing Good User Stories. Over the last few weeks, I’ve written alot about writing good User Stories – you can see them all here: User Stories . User Stories are a simple way of capturing user requirements throughout a project – an alternative to writing lengthy requirements specifications all up-front. As a guide for people writing User Stories, they can follow this basic construct: As a [user role], I want to [goal], so I can [reason]. This helps to ensure that the requirement is captured at a high level, is feature oriented and covers who, what and why. As well as capturing User Stories in the above format on the Product Backlog , User Stories should be written on a card .
The card comprises 3 parts: Card (i.e. the bit above, “as a user, I want…”) Conversation (notes and/or small wireframe to remind people about the feature) Confirmation (the tests that will show the feature is complete) Here’s an example User Story for you to take a look at. Ultimately, User Stories should be small. . * Independent. . * Negotiable . The Easy Way to Writing Good User Stories. Many development shops have opted to writing user stories over traditional feature/requirement documents; however, almost all of them struggle when writing their first batch of user stories. This is not at all uncommon, just like riding a bike, it does take a little bit of practice (but once you get it – you get it).
Writing user stories is dead simple if you follow these simple steps: 1. As a [role], I can [feature] so that [reason] When writing user stories, using this pattern is a for sure bullseye. As a account owner, I can check my balance online so that I can keep a daily balance 24 hours a day. Pretty easy right? As a account owner, I can check my balance online. Feel free to use slight deviations of this template using synonyms: As a [role], I want [feature] because [reason]As a [role], I can [feature]As a [role], I can [feature] so that [reason] 2. When creating new user stories, always hand write your new stories on a single side of a index card using a Sharpie marker. P.S. 3. 4. User Story Estimation Techniques. One of the great things about working as a consultant is the ability to try out many different ideas and adapting your personal favorite process to include things that work.
This article gives the details about user story estimation techniques that I've found effective. Powers of two Originally I estimated stories as one, two, three, four or as small, medium, large, extra-large. It was always meant to be understood that a medium was twice the size of a small and a large was twice the size of a medium (and so on), but that never seemed to translate well when it came to planning. Then someone recommended to me that I try powers of two. Use four values I was once on a project that started with 1, 2, 4, 8 as their estimation values. No averages or numbers not on the scale Four values allow you to get a rough estimate without spending unnecessary time focusing on precision. Vote independently It's human nature to be influenced by other people. Take the largest estimate Large estimate gaps Bribes.