Learn Software Development » Approval

The compromise between having a Product Owner who tries to detail out too much ..

ashish — Mon, 17 Oct 2011 17:42:00 +0000

Scrum suffers from problems where you have a Product Owner role that needs to have a person who has understood the role in good detail. In a lot of cases, just transitioning the role from that of a regular Product Management role to that of a Product Owner role takes some amount of getting used to. So, you need to have a Product Owner who is setup to define a level of responsibility where the Product Owner gives enough detail about the feature without trying to get into a lot of detail.
In the regular Waterfall kind of product development methodology, the Product Management team / person defines a great level of detail for all the features and puts these into the Requirement documents. These are then signed off by the customers (in many of the cases), and then explained to the various teams. In turn, the teams then create design documents, test documents, and do a full traceability matrix from the requirements. This ensures that the requirements are adhered to in great detail, and there is no confusion among the implementation team with respect to the requirements.
So, when a member of the Product Management team starts working as a part of the Scrum team, they are used to the level of detail that they already do in the past. Consider the case where the team has a number of features, and the Product Owner looks at the features, and based on their past record, start breaking down the features into how the screens should look like. In the extreme case, the Product Owner will continue on this line and insist that the team should design the screens and dialogs exactly like how the Product Owner wants it to be, right at the beginning of the cycle.
In Scrum, the Product Owner should take the feature / User Story, and define the User Stories / tasks in such a way that they answer the various queries that the users of the product will have. So, when defining user interactions, these are defined in terms of problems that the users will be looking, not in terms of the screens that will be present in the application. This does not mean that the Product Owner will not look at how the UI of the application should like, it’s just that the UI definition should happen near the relevant Sprint; and in fact, the Product Owner should work with the UI designer attached to the team, and work in advance to get concepts of how the screen should look like.
The difference is that the Product Owner should focus on the ease of use of the application, get feedback on how the workflows can be made more user friendly, and so on. And, since the UI is part of the features that are demoed at the end of the Sprint, there can be more feedback that causes a change in the UI that has been designed earlier. The Product Owner should be ready to modify the UI as and when required.
I reviewed what I have written earlier, and it seems to match what our team does, but seems a bit confusing. Can you comment on how your team works ?

Discord between the Scrum team and the Product Owner on the feature list priority

ashish — Sun, 16 Oct 2011 19:15:14 +0000

This particular post is more of an opinion rather than a stated part of the process (as far as the discussion that I have had with several Scrum Masters has led me to believe). The Scrum process outlines a role for the Product Owner to define the features of the product, and also to determine the Product Backlog (the prioritization of the features that will be part of the ongoing Sprints). At the same time, the Scrum team is an empowered Product team that needs to take up a much enhanced responsibility for the tasks that make up the features, determining the efforts for the various features, and so on.
So where does the challenge come ? Well, the challenge comes with a team that feels much more empowered, more responsible for the features that go into the product, its feature set versus the competition, the needs of the customer and so more. Teams that have taken on more responsibility typically have people who look at customer forums, who interact with customers to get more in touch with their needs, and similar such measures that bring them closer to the customers and their needs.
This has the potential for sparking a conflict, such as when the Product Owner (based on their own research, contacts with customers, and studies of the market) places a few features as higher priority; and then you have team members, who believe that they know the needs of the customer, coming into some sort of conflict with the Product Owner. Now, you would expect that the Product Owner is the one who decides the priority of features and the details of the feature, but when you get a team to become more responsible for the features, get them in closer touch with customers, then they will start to become much closer to the future vision of the product; so if what the Product Owner is saying does not gel well with them, then there will be some sort of opposition. This opposition can make itself known during the Sprint planning meetings, as well as during the Daily Scrum meeting when the team may have some query on some part of the task, and the approach suggested by the Product Owner may be resisted.
Is this a theoretical position ? No, we have had cases where the managers of the team members have to get involved, in order to better understand the position of the team members, and then counsel (and where required, have a quiet word with the Product Owner). Once in a while, we thought about letting such an open discussion happen, but the thought was that such a discussion would undermine the position of the Product Owner and was not the right step to take.

Product Development – Actual Kickoff of Development Effort

ashish — Wed, 29 Oct 2008 07:46:17 +0000

During every product development cycle, there are 2 distinct stages that you reach in the cycle. There is an initial phase when the planning happens, and there is a later stage when the actual work happens with respect to the actual design and development effort. These are very broad level definitions, with many details and finer points.
- Planning stage: This is the stage where the team defines with broad strokes, the details of what the product will look like in terms of features. The general direction of the product, the features that will make it to the release, the schedule of the release, all of these are decided in this stage. In addition, if the company is structured in such a way that the configuration group, installer and release teams, internationalization teams, and other central technology groups are separate teams, then they will need to be signed up.
- Implementation stage: In this stage, the teams get working on actual implementation of features. By this time, the product team has already decided on the features, their priority, and schedule. The core of the development phase, which can be translated into requirements breakup and detailing, user design, engineering design, test case and test plans, coding, testing, and release all happen in this stage.
In between these 2 distinct phases of the project, there is a need to get an actual kickoff. If the product is such that it needs an approval from executive management, and also to get all the supporting team on the same discussion stage, a typical kickoff meeting is called. In this meeting, the project manager / program manager gets all the stakeholders (including the product team, management, executive sponsors, supporting teams, product management, etc) onto the same room and presents the schedule, final feature list, commitments of support, languages, pre-release plans, issues and risks and so on.
Such a meeting typically takes around a month to plan, since you need to get a meeting time right which is convenient for all the attendees, you need to prepare a presentation to run in the meeting, and so on. A kickoff meeting is the actual time when the sponsors say yes to the product development phase proceeding, at the same time, there is also a chance that the executive management team may need clarifications or may even ask the team to go back and review their plans.