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 3

The past 2 posts have been along about how to ensure that the Backlog Management is properly done, and also to try to take measures to improve the way that the Backlog is used. In this post, we will continue our discussion on this topic.
Some more items that a Scrum team (and the ScrumMaster) need to spend some time discussion revolve around the following queries (and trust me, these are queries that you need to answer in order to ensure that you are making your feature / user story development process as efficient and complete as possible).
– Have you properly defined what done means ? Done in the case of software can be subjective sometimes, especially when you throw in the comfort level needed by the testers, and the quality and level of bugs found for the feature. To make these subjective parameters as much objective as possible, you need to specify criteria that help you determine what ‘done’ means. Review these criteria over the course of your project to verify that everybody seems comfortable with this criteria, and can be met.
– Once you have defined the criteria for ‘done’ and made sure that the team is fully aware of these criteria, the next step is to make sure that the team is actually following these criteria. There is nothing that can increase the scope for confusion in a project than when the team does not follow the criteria, or when the criteria are badly drafted. They increase the chance of more subjectivity and individuality being used to determine when a feature is actually done.
– Who all can overwrite these criteria. You all know it, when the project manager or somebody senior comes in and says that we need to get this out of the door, so let us relax the criteria this time. And wham, the team has the message that the criteria is flexible, and would you believe it, there is the feeling that maybe there could be another reason to relax the criteria (or even more so, when the team believes that they are working on a critical feature, and it will be approved even if the criteria is not being met). In some cases, you have to bow down when these deviations are being forced on you, but make sure that you are fighting them.
– Are all the logistics already in place ? Processes already defined ? When I say this, I mean that if some feature work is going to happen that needs a specific set of equipment (hardware / software / space), then those should already be available. Else, there will be perfectly valid reasons as to why the feature was delayed. Further, the lack of such planning typically ends up impacting more than one feature.
– I mentioned it in an earlier point, but need to make sure that when the process for defining a feature being complete is being written, it includes all the testing processes. As per Scrum, when a feature is done, it is of shippable quality, and one would need to ensure that all the required amount of testing cycles and bug-fixing has happened as part of the Sprint estimates.

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>