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.

Scrum: How to develop a product with the required set of features

This remains an ongoing question in teams using the Scrum development model. In an earlier post, I had talked about trying to do estimation of the features by breaking them down into tasks, and getting the team to do estimation models on this and using this method to determine the number of features that can be done with the current team. However, there is a huge amount of variability in this model; when I was starting to use Scrum, this was one of the answers that I got from the trainer, but that this was imperfect. Another trainer at another point of time made the statement that trying to do this kind of estimation was against the concepts of using Scrum, and it was wrong to keep on following earlier targets when the development model had been so drastically changed. Further, even during the Waterfall method when there was a lot of effort to do an earlier approximation, near the end, we would still end up doing lesser features than what had been targeted during the initial discussion.
And then the organization hired a Scrum coach; there were more teams that were employing Scrum, and the cost of hiring an experienced coach was less than the productivity benefits that was expected from the use of the coach for the teams. We had the same question for the coach, and the coach helped us understand one basic concept. As per the explanation that he gave to us, it was not a recommended process to try and do an estimation of all the features right in the start of the schedule in order to determine which features will get done. The concept is that the Scrum team is one of the most efficient ways of getting feature work done and if the teams are able to do only a certain amount of features done over the Sprints, then even a team using Waterfall and an initial estimation of all the features would not have been able to do more, not unless they put a lot of pressure on the team for doing overwork and stressing them out to get more work done (and putting people on stress for long periods of time really has a lot of pitfalls, it decreases the efficiency of people and can result in a product with lower quality).
So, as per the coach, the responsibility of getting the best possible release from the team is that of the Product Owner (and this is not a shared responsibility with the Scrum master or the team). The product owner is the one responsible for setting the Product Backlog, and a part of which ensures that features that are more important need to be done in the earlier Sprints (and even if there are dependency issues because of which the feature cannot be done earlier, those need to be resolved early). Further, the feature at the end of the Sprint has to meet the Done criteria, else the Product Owner should not accept the feature. As a result, what will happen is that by the end of the required Sprints, the team would actually have worked on and finished the most important features along with some others, and if they are of a high quality level, then that is typically good enough for the product to get released with these features.

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>