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 Product Owner – Clear vision vs. evolving thought and adaptability

Scrum has been setup based on some principles that seek to map how modern software projects actually are, with the biggest basic principle being the fact that business requirements keep on changing. Hence, if there is a methodology that requires you to lock all your business requirements at the beginning of the cycle, and makes it difficult (or near impossible) to change those requirements later, then it was time to evaluate how to move to a more dynamic methodology that could adapt to changing requirements; Scrum fits that definition to a much higher degree. So, Scrum mandates that requirements should be frozen only for short periods at a time, which is through the system of having defined intervals such as Sprints, where the Product Owner works to define the requirements for each Sprint, before the Sprint; explaining the requirements in the form of User Stories to the team, and evaluating the performance at the end of each Sprint. This allows starting the project, and defining the priorities of the building blocks for the project as we move ahead, building them one Sprint after another. Another advantage is that, if during the course of the project, it is found that there is changes in customer preferences or in the competitive landscape, the team can make the quick changes to handle these changes.
However, there is an increased pressure on the Product Owner due to all these changes. The Product Owner has to handle all these requirements in an appropriate priority, responding to external changes, while ensuring that the team does not feel puzzled. Also, when building some complicated design, there needs to be a plan to ensure that the basic required building blocks are built step by step in the various Sprints. Towards this purpose, the Product Owner needs to have complete clarity on what he / she wants to achieve in the project, as well as how to go about doing it. There needs to a Vision about what to build, and this Vision should be such that it can incorporate these changes in the requirements over the course of the project. I have seen Product Owners who work Sprint by Sprint, and in the end, things start to go haywire. Items that are required are not there, or the integration between different items start to fail.
The team also needs to have this Vision clarity in their head, and they will not get it until it has been imparted to them (explained in a way that makes sense) by the Product Owner. It is only when they have this overall vision that they will be able to see how the different requirements that they are implementing add up together into the desired project.

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>