Comments on: Get Smart: Storyotypes in your backlog

By: Hal Arnold

Hal Arnold — Sat, 01 Nov 2008 23:07:07 +0000

I agree with VenuT, we drive all our story with story tests. When we feel comfortable with the tests, [which means they're testable] then we know we have something that we can get started on, and that will usually be fairly unambiguous.

I’ve given over to calling them story tests; where we used to call them, either user acceptance or customer acceptance tests. Both these terms really confused the teams, both the customer, and the technical guys. Often the tests are ‘doable’ as unit or integration tests; that is, they prove the point, provide the basis for a satisfying and successful TDD session, focused on ‘customer value’, but aren’t demo-able in a fashion that a normal non-technical customer would understand. So I have given up calling them CATs, even though they are business level tests.

By: Chris

Chris — Fri, 31 Oct 2008 15:56:23 +0000

@Sharan K. Yes stories are meant to be generic, but not so generic that you can’t derive value from it. Especially when you’re writing research spike stories. If these aren’t specific, teams can end up wandering too much and exploring too many non-value oriented items.

By: Sharan Karekatte

Sharan Karekatte — Fri, 31 Oct 2008 15:35:47 +0000

User Stories (US) are meant to be a little generic. They are meant to spawn discussion within the team to come up with concrete Acceptance Criteria (AC). These specific (and testable) AC need to be recorded since they form the basis for all work going forward. The Product Owners and Testers should agree on the AC. Since much thought has gone into these detailed AC, the US eventually becomes testable and preempts (for most part) wandering/drifting.

By: Anand Kothari

Anand Kothari — Thu, 30 Oct 2008 03:11:24 +0000

Great point.

With TDD (Test-Driven Development), one can make sure that the story has test case(s) written first and the validation criteria is also free from ambiguity for the development team to overcome the lack of specificity. It also demands that the definition of done is crisp and measurable. This is something that the Agile team should practice to refine over period of time.

By: Scott Barnes

Scott Barnes — Wed, 29 Oct 2008 21:00:50 +0000

This is why we need strong CSMs. If the story can’t be tested, it shouldn’t be a story. If you can’t test when it is done, you’ll possibly never be done. I have seen those as well. Good coaching quickly remedies this type of issue.

By: Michael Bolton

Michael Bolton — Wed, 29 Oct 2008 16:40:39 +0000

I’m not sure I understand clearly the notion that a story is “not testable”. I think it’s because we have different notions of “testability”. To me, testability is “anything that helps us to ask or answer a question that we might have about a product”. Do you believe that “testable” means a) something that can be made subject to a Yes or No answer (or a set of them) posed by a human; b) something that can be made subject to a Yes or No answer /as asked and answered by a computer program/; or c) what I said; or d) something else?

This is important to me, a tester, because testing is not merely a process of confirmation, verification, and validation. To me, testing is a process of exploration, discover, investigation and learning. That learning is about test coverage–the extent to which we have tried the program to learn sufficiently everything that matters about how the product can work and how it might fail. A program that has been subject only to confirmatory tests (to me) isn’t a program that has been tested; it’s been checked.

Cheers,

—Michael B.

By: Linda Cook

Linda Cook — Wed, 29 Oct 2008 01:06:21 +0000

Yes, teams sometimes have ‘placeholder’ stories. These stories are not estimated or testable in their current state. They are intended to remind everyone of important features that are date sensitive. Instead of working on these vague stories, the teams will spike the analysis so that the real stories with test criteria can be created and estimated. Caution is warranted to be sure not to overload (read create waste) the backlog with features that have little or unknown value.

By: Venu Tadepalli

Venu Tadepalli — Tue, 28 Oct 2008 20:43:16 +0000

Yes, we had a story “convert data.” But, laying out the acceptance criteria helped us understand the depth of the problem.

By: Oana Juncu

Oana Juncu — Tue, 28 Oct 2008 14:38:28 +0000

Hi Chris, we do struggle a little bit with UI stories that are hard to test. In fact, they are submitted only to a classic acceptance test by the product owner; We tried to plan implementation of UI test oriented tools, but thy high degree of set-up complexity vs. recognized value/priority ro the business left it in an endless postponed state.
By the way, I liked the “get smart” stoires, I’ve seen somethink alike in my project experience as “POC stories”.

By: Ben Carey

Ben Carey — Tue, 28 Oct 2008 11:39:26 +0000

Great point. If you do make the stories testable then you could go as far as including sample tests as an outcome of the story. In your example with MVC, the acceptance criteria could certainly still be automated and the resulting tests could be leverage the tests as documentation.

If a team member would play the ASP.Net MVC story, they could write tests that demonstrate the data exchange and distribute the tests as a representation of what was learned. Visibone does this on their quick-reference cards. I think that the tests end up being a great way to distribute the knowledge to the team in addition to the original learning.