So now that I’ve finished my multi-part post on getting the most out of user stories, it is time to provide a nice convenient overview of some essential practices that I’ve blogged about. I don’t have any additional parts planned, but if I come up with something new, I’ll make sure this list is updated.
In this multi-part post, I’m going to share my personal experiences while working with user stories for gathering, tracking and planning requirements. It currently consists out of three parts:
Where do you start?
Suppose that after intensive discussions and tough scoping sessions you ended up with a list of user stories and are about to start building the system. The first story not only needs to realize some particular feature, but also involves building a skeleton implementation of the system’s architecture. How do you avoid spending way too much time on plumbing and other general purpose stuff you need for the rest of the stories?
In this multi-part post, I’m going to share my personal experiences while working with user stories for gathering, tracking and planning requirements.
So who writes them?
That depends. In Scrum it is the product owner (the term I use in the rest of this article) who represents the customer(s), and he or she has full responsibility over the list of user stories that comprise the product or system (the product backlog). And since he is one most knowledgeable about the particular domain, usually he is also the one who is supposed to write the user stories. In reality however, it is a combined effort with the team that realizes the functionality. Writing good user stories is not trivial, you know.