Product Backlog – Does not work if you use as a month by month job
Filed Under Agile, Product Management, Requirements, Scrum | Posted on December 5, 2009
The topic for this post does not sound so easy to decipher when I read it again, but I will leave it there and try and explain what I mean. For those of us doing scrum, we know what a product backlog is, right ? A product backlog is a listing of features that are listed as possible features for the product / project, with the prioritization of the features by the product owner deciding when and which feature makes it. As you get closer to a specific Sprint, the features related to that Sprint are detailed out, while features that are meant for future Sprints will be detailed out later.
All this sounds well and good, especially when you consider that Scrum will help the team from spending too much time on future features that may change due to customer inputs getting clearer, or because the customer has changed their mind, or other similar reasons. So, in an ideal Scrum world, you are able to do features that are important now, and at the same time, be easily able to change future features due to a variety of reasons.
However, this model breaks down when people mix this very strongly with the JIT (Just in Time) concept where the feature is broken down only when you are onto the Sprint planning, and there are no details available for what is required in future Sprints. When a situation like this arises, the team gives estimates that are almost based on a first cut feature definition, and the user story sometimes requires a bit of discussion before you would like to make it final. Further, when Product Management resources are scarce, these feature specs really do not come out with the frequency that you would like. What happens in such cases is that the work is really month to month, with the developer or architect not even getting a clear full product need, which means that design for large parts of the feature may be finalized before you get onto the next Sprint. Now, if there are new features for future Sprints that are not able to be rendered due to a certain design decision taken during the previous Sprint, then the situation can be pretty tricky and require re-work may or may not be extensive.
Moral of the story: Make sure that your people generating the user stories / requirements are capable of generating these a bit in advance of the actual Sprint planning.
|
|
|
If you are interested in software processes, find this post informative, and want to learn more, why not subscribe ?
Subscribe in a readerSubscribe to get updates by Email
Leave a Reply
