My team is using the scrum process. The scrum manual labels the requirements manager role as a product owner. In the context of a software house this is a simple enough role to fill. You get the product manager to do the job. In an enterprise projectthere is a slight difference in how you'll need to tackle the role.
For one thing, an individual will rarely be given the authority to "own' the product. Secondly the needs of multiple stakeholders need to be addressed not just when the product rolls out, but every day the project is in progress as well.
This diagram is from about 6 months ago. It captures an iterative requirements elicitation and definition process. We've stuck pretty close to it over the last few months, but have made some improvements as we go.
In case you can't read the diagram, the steps are as follows.
Step 1; Weekly elicitation meeting.
Step 2; Developer & QA review of and initial estimating review of new requirements
Step 2a; Clarification
Step 3; Add to Product Backlog (in TFS)
Step 4; Introduce to sprint plan
What have we changed? We have elaborated each of the steps with some more detail and we have added some steps.
The new cycle is as follows
Day 1; Requirements workshop
Day 2;
Day 3; Initial estimating session with developer team members
Day 4;
Day 5;
Day 6; BA Backlog planning session
Day 7;
Day 8; QA requirements
Day 9;
Day 10; Sprint reiew, demo prouct
0 comments:
Post a Comment