Training: Agile requirement Management

Training: Agile requirement Ma...-Google Docs

The training is divided into three parts:
The first part describes the basic knowledge of agile demand management. Test 1. (15 ')
The second part introduces 20 specific suggestions. Test 2. (45 ')
Part 3 exercise-New sailors bookstore. (Do you need to use the luofeng group example ?) (30 ')

Preparation:
1. Customers are now divided into three groups. Each group should include multiple roles, such as development, testing, and Po.
2. Prepare a story card. Each group sends 10 story cards.
3. Plasticine.
Opening:
This training is interspersed with several tests. This training is linked to performance.
Part 1:
The invest principle.
Q: Have you ever attended the agile demand management training? Do you understand the Invest principles? What are the most common principles in practice?
Test 1: Split the following story into at least five stories.
As a user, I want to log on to use the services provided by the system. (FTP client)
Reference answer:

1. As a registered user, I want to see the logon success prompt (if I use the correct username and password) so that I can be sure that I can use the services provided by the system.
2. As a registered user, I want to see the logon Failure prompt (if I use the wrong user name and password) so that I can be sure that I can use the services provided by the system.
3. As a registered user, I want the system to retain the user name I entered last time so that I only need to enter the password again.
4. As a registered user, I want to see the logon prompt (if I directly access the functions provided by the system) so that I can know that I should enter the user name and password.
5. As a non-registered user, I want to see the registration prompt (if I directly access the functions provided by the system) so that I can know that I should register. (?)
6. As a registered user, I want to enter the user name in a command line (also need to prompt me to enter the password) so that I can log on quickly.
7. As a registered user (familiar with command line operations), I want to enter the user name and password in a command line so that I can log on quickly.
8. As a registered user, I want to save my username and password locally so that I can log on automatically.
9. As a registered user, the user name and password I want to save locally are encrypted so that my automatic login information is secure.
10. As an anonymous user, I want to directly access services with anonymous permissions so that I can quickly use the services provided by the system.

Send representatives to each group to post and describe the splitting results of the group.
Please comment on each group.
Record the comments on the whiteboard for the following 20 suggestions.
Part 2 (story analysis of three major categories A, agile estimation of B, and C iteration plan and tracking ):

1. Prepare chestnuts.
2. Follow roles.
* Do not use a uniform "user ".
* Use a typical user. (What do users do with the system? How to use it? What is the background of the user ?)
* User role. (Name, age, character characteristics ...)
* Contact the previous example: a user registered, a non-registered user, or a user familiar with the command line...
3. Use a language that the customer (at least the tester) can understand to describe the story.
* The Word "Port" may be inappropriate in a project for common users, but it is appropriate in the projects of shutong.
4. Use the acceptance conditions to help split the story.
5. Use the Fibonacci sequence: 1, 2, 3, 5, 8.
* The base point is 2.
* Do not use a larger value.
* Do not make an average. Try to use a larger one.
* Accuracy is not equal to precision.
6. independent voting.
7. Consider the unknown factors separately.
8. The po and test have the right to question.
* The inherent complexity of a story is fixed.
9. Use different units for the master story, such as large, medium, and small.
10. Record your assumptions.
11. Update estimates in a timely manner.
12. Burn stories, not tasks.

I heard Mike Cohn, author of user stories applied [coh04], talk about focusing on the role when writing user stories at the agile 2006 conference. the example he gave was that of an airline reservation system, pointing out that the regular business traveler booking a flight wants very different things from such a system than the occasional vacation traveler.

RJ:

What I recommend as a planning process is this:

1. Product owner writes story on whiteboard, and explains it.
2. Briefly discuss how the story will be tested.
3. Developers briefly brainstorm and list technical steps needed.
(Similar to tasks but we're not going to do the work, nor track it that way .)
4. Repeat until enough stories are on the board.
5. Look at the list, draw the line where you're confident you can accomplish everything abve the line.
6. Commit
7. Do stories as a unit, not broken into tasks.
8. Burn stories, not tasks.

In order for this to work, the stories need to be small enough that the team can understand and estimate them well. one approach to decomposing a story is to list the acceptance criteria, and then look at each of these and find the ones that can be stories themselves. if the specified acceptance criteria adds some value to the product, is user visible, stands alone, and is testable, then it is a good candidate to become its own story.

precision = accuracy! [But it feels like it…]