I am trying to implement Scrum and have some basic questions. I understand creating stories to implement end user functionality, but where does a "meta-task" like collecting requirements for the stories in the first place come from? Is this even before the story process begins? I guess I am struggling with the fact that a project starts up at some point, and then tasks like "get requirements" and "create user stories" are needed, but those are also part of the project and need to be captured somewhere. Do they fit into Scrum stories? Are they part of a sprint? It seems like they should be, but creating stories for them seems recursive...I hope that makes sense. Thanks!
-
This can be related: programmers.stackexchange.com/questions/61529/…– Ladislav MrnkaApr 10, 2011 at 11:30
Add a comment
|
5 Answers
The short answer is "No, there should be no stories created for tasks which deal with managing the SCRUM process itself".
User Stories are exclusively for describing user-oriented (or also "owner-oriented") features which will be implemented into the product.
I think that the main reason for not mixing these with meta tasks (such as creating user stories, rating them etc.) is that meta tasks typically imply a particular sequence relative to other tasks, whereby user stories can be implemented in any order, in the very first sprint or the very last. Certainly, the way stories are rated and prioritized by the Team and the Product Master influence the order in which they are introduced into the product, but ideally they are independent from one another and hence interchangeable with regards to planning.
It is often hard enough to select a good set of stories for a given sprint without adding further confusion with meta tasks.
Meta tasks (such as creating stories, planning a Sprint, scheduling daily SCRUMs and various administrative tasks) are therefore part of the SCRUM process. They are built-in the framework and are not explicitly tracked.
-
@mjv - Thanks for your response. I have an additional question. If the additional tasks aren't tracked inside of SCRUM (which I agree is reasonable), don't they need to be tracked at "some level?" When doing a project and saying "we need to get this sprint done in X amount of time" there has to be somewhere to capture all of the additional "stuff" that needs to be done that doesn't directly relate to the sprint, but yet eats up person hours.– skazApr 7, 2011 at 12:02
-
@skaz, time spent on those tasks should be tracked (if you need to track them at all) as part of the individual stories.– MarcieApr 7, 2011 at 15:04
-
@Marcie - but mjv's whole point above was that these should NOT be tracked in stories.– skazApr 7, 2011 at 19:52
To get requirements and to write user stories are not tasks. They are a full-time job. The product owner's job.
What you describe in your question is "Iteration 0" when the requirements are discovered and user stories are written. Then the team goes to work and implements them in Iterations 1 through N.
But requirement discovery never stops. The product owner can at any future moment add or delete requirements, merge or split up user stories, and re-prioritize them. This is how agile does adaptive planning ("responding to change over following a plan").
Scrum is for builders (developers). The things you are talking about are done by product owners. Product Owners are a part of Scrum in that they facilitate the process, but in their own work they do not do Scrum.
I worked for a company that did try having the Product Management group (actually, every group but Sales) do Scrum. Every group but the developers abandoned it within months.
Some of the principles like task breakdown and assignments were preserved, but velocity and sprints were some of the things that didn't really work.
As a sidenote, I also recommend that the Porduct Owner prioritizes each User-Story. The story with the highest priority is done first, same for the story-tasks.
Specifically, "collecting requirements" is part of the development process for each individual Sprint backlog item. So any estimate for a SB item needs to be "soup to nuts", from sitting down with the user to discuss what they really want right through to final acceptance testing.
Product Backlog items, on the other hand, need to have only enough detail in them so that everyone understands knows they're talking about the same thing when they refer to it. So a PB item with only one word, "Bagels!" is fine as long as everyone knows what that means. That's why User Stories are popular, because they give a one sentence description that tells everyone everything they need to do the planning. As mentioned above, going from that simple description to detailed specifications is part of the development work done in the Sprint.
So the overhead for the Team in maintaining the PB is minimal, and continually happens in tiny little chunks of effort throughout the project. When you get close to Sprint planning, the developers may need to provide very rough estimates for the higher priority PB items, but these really don't need to take more than a few minutes each.
