Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

More about the Product Backlog – When and where ?

In the previous post (link), I had started writing about the Product Backlog, but soon realized that I needed more than one post. So here is Part 2 about the Product Backlog.
Part of the debate about a Product Backlog is about the extent of detail, as well as when should more detail be added. Now, Scrum is all about not adding detailed requirements well ahead of time (Waterfall, anyone?); it is about getting details in when these details are required by the team to start implementing the required user stories. However, if you consider the situation where, for a given Sprint Planning, the top items in the Product Backlog (as optimized by the Product Owner) contains only single statement requests, you do not have enough detail to start work. One can envisage spending a lot of time in the Sprint Planning sessions where the feature needs to be detailed enough so that estimates can be made. However, for the case of user stories where the workflow is complex or needs to be detailed, you need the User Interface Designer to have already spent some time before the team can make estimates and start working on the tasks. For this purpose, you would need the Product Owner to have spent the required time with the UE team so as to have added more details to the user story, and then the User Interface Designer to draw up the required workflows. It could be argued that if the workflow / user story is so complex that it would require so much pre-work, then maybe the user story has not been stated clearly enough. However, for many UI interaction heavy tasks such as portals, shopping carts, etc, it is required that this kind of pre-work be done; although you only need to do it as the relevant Sprint appears closer, as opposed to doing it much earlier. One advantage of doing such pre-work is that several different UI’s can be generated, and user feedback sought from a sample set of users. This helps in ensuring that the final product will be closer to one that customers want.
Further, taking such a approach means that the user story can be refined, and also broken down into several smaller user stories, with the additional advantage that estimation for such tasks can be done with a greater amount of efficiency. One thing to keep in mind is that you need not reach a final detailed UE, instead a UE that is good enough to guide the team can be done upto the Sprint planning, and the UE finalized during the actual Sprint cycle.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>