Re: UseCases in the Backlog / WAS: Requirements
Our teams tend to use User Stories as our basic way of capturing project
requirements. In other words, Product Backlog Items == User Stories for us.
We expand on those User Stories in different ways with different artifacts
depending on the requirement -- sometimes we create Use Cases, sometimes we
create UI wireframes, sometimes we just capture a few simple business rules.
As an example, for a User Story like, "As a site visitor, I can submit my
credit card information to pay for a purchase," we'd probably just capture a
few business rule like: can use Visa, Mastercard, Amex; payment gateway is
InternetSecure Inc.; merchant account is XXXX at Bank AAAAA and so on.
But if, say, for some reason Visa and Mastercard transactions needed to be
processed differently and it was important to the succesful implementation
of the Story for developers or end users to know the specific steps and
exceptions for each, we'd probably document those steps with one or more Use
Cases. (I learned how to write use cases from reading Alistair Cockburn, and
I do most of the Use Case writing around here, so our Use Cases tend to be
In terms of where the Sprint Backlog comes into it, we might capture "write
a use case for X" or "document business rules for Y" as Sprint Backlog
items. But, also, sometimes the need for a Use Case emerges spontaneously
and if we can just bang one out in half an hour or so, we don't bother to
create a Backlog item for it.
[Get ideas, tools and insight to help your organization grow online.
Subscribe to Xaccute Ideas@Work Quarterly. Sign up now at
http://www.xaccute.com/newsletter and earn a chance to win $100 from
xaccute interactive :: solutions that connect
+1.416.628.4880 :: toronto vox
647.722.0059 :: fax
1.866.576.4688 :: toll free
m.kent@... :: mobile msg
callto:kent.wakely :: skype