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.

How to ensure that Scrum Backlog Management is ensured, to ensure that the team is on the path of success (contd..) – Part 2

In the previous post (Project Backlog Management), I talked about some of the problems that Scrum teams face in terms of Backlog Management, when they find that their Backlog does not seem to be coming down over a period of time, or when their demos at Sprint end do not seem to provide satisfaction that everything got completed, and so on. Such issues can pose serious problems, and lead stakeholders to believe that something is going right (and more specifically, can give an impression to the Product Owner that feature implementation is either slow or not happening). One needs to address such problems pretty fast.
First of all, the ScrumMaster would need to determine where the exact problems lies; in terms of Backlog Management, this can be either in terms of features not being clearly defined at the initial Sprint planning and estimation stage, or some problems in the estimation, or the Backlog for each Sprint (also called Sprint Backlog) not being maintained (and the Sprint Backlog is not maintained by the Product Owner, but by the team). It can also be that the team is not following the rules and processes enough, and as a result, the resultant deviations are causing problems to the feature closure and overall to the Backlog Management.
So, what needs to be done ?
The first step is to determine whether the team is actually following the desired Backlog Management. A series of questions can help in determining this.
– Is somebody in the team (should be the ScrumMaster) making sure that the Backlog is maintained to be accurate atleast once every couple of days. If not, then the Backlog gets out of date, and loses its usefulness as a way of ensuring that the overall Product Backlog and the Sprint Backlog reflect the remaining set of desired feature
– This one is more challenging for Product teams with a lot of inter-dependencies. The aim of each Sprint is to ensure that the features defined for each Sprint will lead to a product at the end of the Sprint that is shippable (although this is one of the parts that I find teams struggling with). The use cases that a feature is broken down can be completed partly at the end of one Sprint, and the others are the end of the following Sprint, but in many cases, when the feature is complete, only then is the product considered in a shippable state. However, many times, the teams do not even make the effort, and that is when they are condemned to failure.
– And one of the major problems, much more fundamental, is a Backlog actually maintained ? This is a basic requirement, without which the teams will take up features in any manner, without prioritization, and without ensuring that the dependencies and cross-referencing that needs to happen while setting the order of execution of features will not happen.
– In many cases, the team literally takes the concept of a Backlog to mean only features, and not bugs. As a result, the calculation and estimation go for a toss, and so can the overall accuracy of the Backlog Management, and its power as a tracking of features. What will happen in such cases is that the team will almost never meet its required level of features for the Sprint.

to be continued …

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>