Do you like to become a part of an agile company? Do you want to be a product manager but do not know what should be done to be more efficient? Please keep on reading till the end.
Why is Agile Product Management Different?
Pichler made a table that answers this question efficiently.
| Old-School Product Management | New School Product Management |
| Several roles, such as product marketer, product manager, product manager, and project manager, share the responsibility for bringing the product to life. | One person—the product owner—is in charge of the product and leads in the project. |
| Product managers are detached from the development teams, separated by process, department, and facility boundaries. | The product owner is a member of the Scrum team and works closely with the ScrumMaster and team on an ongoing basis. |
| Extensive market research, product planning, and business analysis are carried out upfront. | Minimum up-front work is expended to create a vision that describes what the product will roughly look like and do. |
| Up-front product discovery and definition: requirements are detailed and frozen early on. | Product discovery is an ongoing process; requirements emerge. There is no definition phase and no market or product requirements specification. The product backlog is dynamic, and its contents evolve based on customer and user feedback. |
| Customer feedback is received late, in-market testing and after product launch. | Early and frequent releases together with sprint review meetings generate valuable customer and user feedback that helps create a product customers love. |
Agile methods involve collaboration between the business and the team. And there should be a confident person to connect these guys and accept the responsibility of the product. No one is better than a product owner.
The product owner is in charge of the value of what the scrum team does and their finishing product. He also has authority over the product backlog and the product itself. He just says about what should be done, but not the how-to or how long it might take.
Change scrum team compositions irregularly, as it’s a small, cross-functional team that makes the product. These small changes can help the association of the teams with products. As each team will own a product for a long period.
The product owner should be a leader and not a boss and should help the team with hard decisions. As with decisions, there will be arguments and disagreements before finding a solution.
The product owner is the representative of the customer. And he should communicate with the ScrumMaster who is the representative of the team. The product owner is responsible for making the right product and the ScrumMaster is responsible for making it the right way.
Upper management should support and sponsor the product owner. “Organizational recognition of the authority and responsibility of the product owner role is a critical success factor for scrum adoption”.
The product owner is a team player who should involve stakeholders as well as acceptance of feedback and customer input while developing the product backlog. stakeholders should join the sprint review and be honest while giving feedback. The product owner should take care of and protect the team, and channel the coming up needs so the team gets involved more productively.
The product owner should spend time with the team in the team room at least one hour per day, but his too much availability can have a negative impact.
Common Pitfalls and Anti-patterns:
- More than 2 people work as owners of the product while neither of them is actually in charge of it.
- Entrusting incompatible authority in the product owner.
- Splitting the product owner role between different people.
- Over-working the product owner. Agile is about sustainability and over-working certainly has no place in this school.
- Failing to fulfill the role of a product owner correctly, as he is given other jobs as well.
- Insufficient support from the team and the ScrumMaster.
- A proxy product owner. The dubbelganger increases miscommunication and hindrance in productivity. Finding a new product owner is better than having a guy working in the place of the authorized product owner.
“The vision describes why the project is being undertaken and what the desired end state is.”
Qualities of the product vision
Shared and unifying. Everyone related to the product should get involved in visioning activities.
Broad and engaging. The vision should be comprehensible yet lets in creativity and engagement of the people during the development process.
Short and sweet. A vision should always be short with only critical information.
Creating product vision
- Using Pet projects: “activity or goal pursued as a personal favorite, rather than because it is generally accepted as necessary or important.”
- Using Scrum: other than building software they can build any kind of artifacts as long as they are “working”.
- Making Prototypes and mock-ups. They will help you with experimenting with your ideas and vision and see the cause and effect if you use prototypes rapidly.
- Personas and scenarios. Just like prototypes, the same works happen. You can check the book This is Service Design Methods for better understanding of what you can do.
- Vision box and trade journal review. It’s like a branding campaign but to see what and much value the package of the product will add.
- Kano Model. A model to classify the customer’s requirements and satisfaction.
The best design is not the one that has everything, but the one that takes out as much as it can, to get the product to its core. Try to make the UI as user friendly and simple as possible.
“Do less than your competition to beat them.”
The product roadmap
“A product roadmap … shows how the product is likely to evolve across versions, facilitating a dialogue between the Scrum Team and the stakeholders.”
“A product road map should state for each version the projected launch date, the target customers and their needs, and the top three to five features.”
It is better to have the map for 6 to 12 months.
Common mistakes
- No vision. Any product should have a vision, and ideas and features should be there to achieve that vision, or else, it will be an unusable product.
- Prophecy vision. Try to select a narrow set of customer needs, with nearer timescales, make prototypes and personas and adapt them. So nothing would go wrong.
- Analysis paralysis. Prediction is not always good. It is better if you get a product to the potential market and analyze the feedback and outcomes in person.
- We know best what is good for our customers. Involve stakeholders in creating the vision, the sprint reviews, and the development process. As they should give feedback so the organization can build a usable, wanting product.
- Big is beautiful. Minimal products being released early can bring in feedback, which can help out in creating the last product.
What is the product backlog?
The product backlog is a prioritized list of user stories that might be needed in the product.
The DEEP qualities:
Detailed appropriately: Higher-priority user stories will have more detail and are smaller but gradually they become larger with fewer details because the team cannot act on them.
Estimated: The efforts should be estimated with a standardized measure according to the team. Stories at the top have more precise estimations.
Emergent: the product backlog gets updated regularly and the details and priorities emerge from the processes and the feedback.
Prioritized: backlog should be ranked based on the value and strategic purpose of the items, which is top to bottom kind of place.
Keep in mind that risky and uncertain items should be prioritized first, the sooner you learn about the risks the easier the process will be until the end.
Prepare for sprints
Goals help with the purpose of the sprint, grind the backlog priorities, and ease of communication about what is meant to be accomplished.
Product backlog items should be detailed with requirements, resources, ways of implementing, dependencies, etc,. that bring benefits.
As the stories reach the top of the backlog, they should be broken down into smaller sizes to be clear, testable, and achievable stories.
Common Mistakes
- Disguised requirements specification: it happens if the relationship between the product owner and the team is not in a good condition. Try to make a product vision, or if it is available, make a new product backlog and discard the disguised requirements.
- Wish list for Santa: an unrefined backlog with what everyone has thought of is a failure. Emerge a new one from a quality vision.
- Requirements push: the product owner should not write the product backlog alone. Scrum team members should always be involved.
- Grooming neglect: If the backlog is not groomed before sprint planning, then it will be a hell, and the sprint will go wrong.
- Competing backlogs: In every sprint, only one product backlog should be discussed.
On planning the release:
- the team should do it and the product owner should lead it.
- it should be focused on the next release.
- Should be soon
- Should have less scope, more quality.
And in the end, you should plan and execute another release soon after that.
Iron triangle
Time vs cost vs functionality
This triangle consists of a high standard. Set the time fixed, and make the functionality flexible, so the goal will be released on time.
If you hold functionality fixed or guess at the scope are bad ideas, because you are not sure about the functionality and everything of the product until you build it.
Try to get sooner feedback, sooner deriving value, keep the testing and releases cost down, test automation, and careful upgrade process. Try to have frequent early releases say quarterly.
The release plan is like a product roadmap, which focuses on the next release and it should be at most three months from the last release.
Common mistakes
- No release burndown or plan: Have a plan and don’t think about only sprints. Explain it to the people of the team.
- Product owner in the passenger seat: this happens when the product owner is not collaborating with the team on the release plans.
- Big-bang release: as it has been said before this will leave less space for feedback and learning.
- Quality compromises: cut lots of scope until the pace, the software, and release cycles are sustainable. And try to release sooner and more often.
Sprint Planning
The product owner does not plan the sprint but he should be there to make sure requirements are available and help the team understand the vision. What should be done is the part that the product owner should answer, but the “How” parts are the team’s part.
ScrumMaster guides the planning of the sprint, and the product owner supports it with the backlog, the reason for prioritizing, and the big picture.
So how can work be DONE?
The definition should be agreed upon. It requires some measures and descriptions to make this definition.
Daily Scrum
It’s like informing about daily tasks and what has been done, what you will do next, and engaging the team in reviewing the giving feedback. Also identifying the work that the team suggests is done, is another part of it.
Remember that the product owner should not have anything to do with the team’s self-organization, do not give tasks, do not comment on individual progressions, and should not tell them what to do.
Sprint Backlog
Sprint backlog includes all activities needed to achieve the sprint goal, it is created in the sprint planning meeting and is updated daily.
“The Sprint Burndown Chart makes the work of the Team visible. It is a graphic representation that shows the rate at which work is completed and how much work remains to be done. The chart slopes downward over Sprint duration and across Story Points completed”
“If the stakeholders are interested in the progress of the sprint, they can join Daily Scrum as silent observers and the sprint review meetings as active participants.”
In a sprint review, demo and test the software. The purpose of the meeting is to be clear and real about the product, and not about impressing people. The product owner should be honest whether the commitments of the sprint are fulfilled or not and should not talk about the team members individually.
As the stakeholders give feedback, the team is not necessarily committed to do exactly as they say but to listen and understand the feedback and to welcome the ideas. The team should digest and think about the suggestions and respond to them with respect.
Sprint Retrospective
Via the sprint retrospective process, the team examines how work is carried out and identifies ways to improve it.
Common mistakes
- The bungee product owner: again and again, the product owner should always be available, and his responsibilities must be a top priority.
- The passive product owner: the product owner should be engaged in the sprint review as it is about creating a successful product together.
- Unsustainable pace: never pressure people to work more hours or harder, get everyone together to search for a better way with respect.
- Smoke and mirrors: The point of the sprint review is to discover and remind of the reality of accomplished progress and what is yet to be done.
- Reporting up the sprint burndown: The sprint burndown artifacts are not status reports! Use roadmaps, release plans, sprint reviews, and release notes.
The status updates should be reported outside the team on the interval of every two or more weeks.
How to become a great product owner
Time and dedication are the essences of becoming a good product owner.
- Say what needs to be done and not how to do it or how much it will take.
- Challenge the team, don’t force them.
- Try to build high performance. Don’t focus too much on short term deliveries.
- Try business-value-driven-thinking. The original scope might change.
- Do not put stress on the team with outside happenings until they become real.
- Incorporate change between sprints. Don’t allow scope creep during sprints.
Register in a scrum product owner training course, if you want to become a product owner.
Understand the agile work and live the Scrum Values.
- Be committed to the team
- Be committed to the product
- Focus on the job
- Be open and clear
- Respect others
- Be encouraging and do the right things in the right ways
- Be a team player
- Trust your teammates.
The top management should recognize the authority and responsibility of the product owner role as an important success factor for any Scrum adoption.
- Different products need different product owner characteristics.
- Different organizations find different ways of staff this role.
- Not everyone can be a product owner.
- A product owner should be empowered or will lose credibility.
- The product owner is a full-time job.
“Applying for the product owner role effectively is not only the cornerstone of making agile product management work. It is also a learning process for the individuals playing the role and for the organization.”
Bibliography:
Download for Agile Product Management with Scrum
You can also get an additional amount of interesting knowledge about this content. With our newsletter, you will get an efficient set of tools to learn a lot about topics focused on services & digital product building. Read more.