Discitur Project
The product Backlog used has various fields. Those are the more useful:
| ID | Title | User Story | Description (Tasks) |
Imp. | Estimate s.p. |
How to Test | Notes |
|---|---|---|---|---|---|---|---|
| 1 | Login | As a teacher I would like to logging me in order to avoid having to re-enter data each time my profile (materials, school type) | 1) Feature to insert username/password
2) service to check data 3) Insertion on cache of autenthication token |
5 | 2 | You enter wrong data and verify that the system does not allow access to personal data They fit right data and access to the personal data, which are cases, personal data collected in registration | It serves to verify the password encryption and to manage safe navigation subsequently |
| 2 | Personal data management | As a teacher I wish I could change my personal information in order to update the materials and for security update password | possibility of display the collected data in recording and ability to edit password, etc. | 2 | 2 | do Login, enter on personal data area, check the data ... | subsequently manage secure navigation |
| 3 | Sign up | as a teacher I would like to sign up so you do not have to repeat my data continuously and receive updates via email for new lessons included | 1) UI for entering credentials, with checks password strength (with confirmation),
email (== username), name, surname, role,
disciplines...
2) service and DB for data persistence. Verify the uniqueness of the account 3) to provide tag the lesson |
3 | 4 | Initially can be entered accounts manually |
- ID: unique indentifier. Sharing with other teams, via mail, it’s always better to refer to an ID
- Title: user story name, feature name
- User Story: one of the aspects of SCRUM. It’s described in the for of “as <user> I want to <feature> in order to gain this <value>”. It may seem redundant (and sometimes it is), but never underestimate its importance: it is essential to think in terms of value to the user end it is important to understand if that is precisely the value it brings to the user, it is important to understand the priorities, it is important to improve their understanding in terms of functional detail. Consider, for example, Sign Up Story in the previous example, surely the task-list extracted would not be the same without the user story
- Description (Tasks): the division into components and tasks to be carried out of the user story. It’s bread for developers, it is prepared by the technical department as a result of discussions with theProduct Owner.
- Importance: two key features:
- More than the number is higher, the user story is important for the user
- There may be NOT two user stories with the same importance. also when the user story which look similar should be intensified among the two is more important
- Estimate (Story point): The estimate in story point. Assume a story point as a day/man (ie 8 hours fully dedicated to the activity). I find it effective to split the estimate in more detailed estimates, ie dedicated to UI, services, data structures, testing, refactoring. I am missing a team to make poker planning …
- How to Test: for my desire to TDD is very important; in general is a way to focus in advance aspects which serve to better detailed functional requirements.
- Notes: of any kind, especially tecnical. Even in this case it serves to better clarify the scope of activities.
In these fields, add fields linked to the state, the sprint they have in common and, in general, any other field could simplify a grouping of user stories.
Comments