Product backlog is normally the starting point, it is where AGILE's heart lie. It is the first step in starting an AGILE based software development. It is nothing but a sorted list of requirements/feature requests/user stories or what ever term you use for high level tasks based on importance of the items in it. The best part is that the items are described in Customer's language which he understand basically the one which reflect the business benefit for him. Lets call these items user stories or backlog items.
Name – It is a short descriptive name of the story. Length should not be longer than 4-12 words. e.g. “Generate the employee attendance report”. It should be small, crisp, distinguishable and communicative so that stake holders knows what we want system to do. Stake holders include developers, testers, product owner.
Importance – It is the importance rating given by the product owner. There are many theories circulate around what should we use as the rating number. some suggest using P1 to P5, other says 1 to 10. I have read an interesting article which says we can use some large numbers like 21 or 135 etc, where higher the number more it has the importance. The motive behind this is to have unique importance number between stories. Second logic which is supporting it says that lets say you rated one story as P1 or 1 what will you do if a new story comes up between the iteration which is higher in importance that this one. Would you rate it as -1 or 0.5? Secondly with using high numbers we should leave some gap between importance numbers like story 1 may have importance rating of 10 and story 2 may have 9. This way is a new story comes up which is high in importance than story 1 but less in importance than story 2 we can accommodate it in between without using making sheet look ugly by making it as 2.5 or fractions. Nice thought :).
estimate – the first assessment of how much work is needed to complete this story. The unit of storage can be of your choice, normally we use a terminology called story points. The story points are usually corresponds roughly to “ideal man-days”.
- You can ask the team with a optimum number of people usually 2, in how many days you can finish a complete demonstrable & releasable version of this story. If the answer comes like "with 2 guys we will take approximately 3 working days" then the initial estimate is 3 X 2 = 6 story points.
- The concentration is not on getting every things absolutely right in the first place but the concentration is to check the relative estimates that means that a 4-point story takes about double the effort as compared to a 2-point story.
(Note: If you practice TDD (test case-driven development) this description can be used as pseudo-code for your acceptance test code. )
Notes – any other info, clarifications, references to other sources of info, etc. Normally very brief.
PRODUCT BACKLOG (example)
| SID | Name | Imp. | Story Points | How To Demo | Notes |
| 1001 | Allocate Employee to Project | 40 | 7 | Log In, Open Employee Detail Page, Change Employee Department from Bench to "Project X", Check the Employee Status in the Employee Detail Page | Need to create the class hierarchy |
| 1002 | Check Employee Allocation History | 25 | 3 | Log In, Go to "My Detail" page, click on Project History | Need to modify the css for this page. |
As the author of this sample excel sheet said and I agree that these are the basic 6 fields we need at the end of the day. You are free to add up whatever fields you want but a easy going product can survive in these fields. I myself is fan of using excel as Product sheet, it gives you lot more freedom and great control. You can allow product sheet to be in control of the "Product Owner" or you can feel free to share in on a machine with all team members, allowing them to add new stories as and when they arrive but always remember that only "Product Owner" has the right to set importance or write estimates.
HOW WE DO PRODUCT "BACKLOGS"
The last thing you want to do is to place the Product Sheet in the version repository, a good idea would be to rather place it on the shared drive. This way you can allow multiple people to access the same without causing locks, merge conflicts etc.
Additional story fields
Sometimes you may want to use few more additional fields in the product backlog based on your project's priorities, I will try to list few which are pretty common.
Category– It is a rough categorization of the story, for example “UI” or “performance”. This way the product owner can easily filter out all “UI” items and change their priority , etc.
Components - Best way is to realize it by “check boxes” in the Excel document, for example “client, middle ware, server”. Team / Product Owner has to identify which technical components will be required in completing this story. This will be typically useful when you have more than one Scrum teams.
Requester – Here as part of reporting, product owner may like to keep track who has requested for the feature to keep him updated on the progress.
Bug tracking ID – It will be useful to keep track of any direct relation between a story and reported bug(s). Specially if you have a separate bug tracking system, like we have Bugzilla.
How we retain the product backlog focus at a "business level "
It is worse to have a Product Owner coming from Technical Background, but in our case we couldn't help it. We didn't found anyone else suitable. The nightmares it caused initially was adding stories like this one "Add composite primary key to the crystal_soak tables”. Why does he want this? The real underlying goal was definitely something like “to disallow user from adding same soak twice for a particular crystal”. It may turn out that there was no primary key since crystal can be associated to more than one soak and thus users were sometimes by mistake associating the same soak more than once. It was something completely different. The team is normally better suited to figure out how to solve something, so the product owner should focus on business goals.
When you see technically oriented stories like this, you should ask the product owner a series of “but why” questions until we find the underlying goal. Then we rephrase the story in terms of the underlying goal (“disallow users to associate duplicate soak to same crystal”). The original technical description ends up in the note column (“Creating a composite primary key might solve this problem”).
0 comments:
Post a Comment