Stakeholders write user stories – User stories are supposed to be simple, with simple description and acceptance criteria. Use business language. Remember non-functional requirements – Stories can also include a variety of requirement types. Indicate the estimated size – A story should include an estimate effort. The developers currently do this during the iteration planning meetings and can include technical detail. Indicate the priority – We prioritize through the placement of the story. Include a unique identifier – We should include an identifier so we can trace back stories to their original requirements documents and/or project request forms.
Stakeholders write user stories – User stories are supposed to be simple, with simple description and acceptance criteria. Use business language. Remember non-functional requirements – Stories can also include a variety of requirement types. Indicate the estimated size – A story should include an estimate effort. The developers currently do this during the iteration planning meetings and can include technical detail. Indicate the priority – We prioritize through the placement of the story. Include a unique identifier – We should include an identifier so we can trace back stories to their original requirements documents and/or project request forms.
Stakeholders write user stories – User stories are supposed to be simple, with simple description and acceptance criteria. Use business language. Remember non-functional requirements – Stories can also include a variety of requirement types. Indicate the estimated size – A story should include an estimate effort. The developers currently do this during the iteration planning meetings and can include technical detail. Indicate the priority – We prioritize through the placement of the story. Include a unique identifier – We should include an identifier so we can trace back stories to their original requirements documents and/or project request forms.
Stakeholders write user stories – User stories are supposed to be simple, with simple description and acceptance criteria. Use business language. Remember non-functional requirements – Stories can also include a variety of requirement types. Mike Cohn often has said that non-functional requirements should be considered “constraints” on the system or development team. Indicate the estimated size – A story should include an estimate effort. The developers currently do this during the iteration planning meetings and can include technical detail. Indicate the priority – We prioritize through the placement of the story. Include a unique identifier – We should include an identifier so we can trace back stories to their original requirements documents and/or project request forms.
Stakeholders write user stories – User stories are supposed to be simple, with simple description and acceptance criteria. Use business language. Remember non-functional requirements – Stories can also include a variety of requirement types. Mike Cohn often has said that non-functional requirements should be considered “constraints” on the system or development team. Indicate the estimated size – A story should include an estimate effort. The developers currently do this during the iteration planning meetings and can include technical detail. Indicate the priority – We prioritize through the placement of the story. Include a unique identifier – We should include an identifier so we can trace back stories to their original requirements documents and/or project request forms.
Conversation – if requirements are written down, what happens? [the PO will get what he wants?] OR [The PO will get what is written?] – Words are imprecise. The story we write on cards is less important than the conversations we have.
Show teams balloon. Acceptance criteria and requirements – I will provide. Built test harnesses, templates, requirement specs Defining acceptance criteria is not the same as writing tests or test cases. Automating acceptance tests can be very helpful The investment in creating better requirements and acceptance criteria is worthwhile and has high return!
There are many different ways of gathering user stories. Here are some of them
To have a better understanding of prioritization we must look at the MoSCoW method through the lens of Kano’s model of quality Objective quality is the conformance to requirements Subjective Quality pertains to the satisfaction of users
To have a better understanding of prioritization we must look at the MoSCoW method through the lens of Kano’s model of quality Objective quality is the conformance to requirements Subjective Quality pertains to the satisfaction of users
Why do you want a button? // To go to the next screen Why do you want to go to the next screen? // So I can skip ahead to other parts of the questionnaire Why do you want to skip ahead? // So I can save time on non-required parts… Why do you want to save time on non-required parts? // So I can help more customers in less time.