How do I prioritize features when it’s ALL really important?
Remember the 80/20 rule. Studies confirm that 80% of customers use 20% of the features of the product. Pick user stories that affect the most people or have the most value to the customer.
There is often the temptation during a development project to try to identify every possible thing that could ever be needed for the conceivable future. It is natural to want to take the biggest bite of the apple when it is offered. However, trying to predict everything that could ever be needed is nearly impossible. Things change too fast.
The solution is to focus on the parts of the system that are super critical to the organization or the customer. It may be that you can identify one feature – such as an intake workflow – that is used by every customer and is critical to the business, while another feature – such as a change of address workflow – presents a cumbersome manual process to customers. It is tempting to focus on fixing that manual process to make life easier for customers, but ultimately the intake workflow should be given the higher priority because it is absolutely essential.
I report to executives who think we’ve bought “x” . . . so when priorities and timelines inevitably change, how do I explain that things have come up, taken longer, etc?
Develop a habit of communicating simply, clearly, and often with your executives so everyone feels like they know what’s going on. Write into the project plan that changes will occur and will be communicated.
Nobody likes surprises when it comes to project status. From the beginning, set an expectation that there will be changes throughout the project lifecycle. When changes occur, talk openly about what you’ve learned that prompted the changes.
One way to do this might be to have a standing, short, biweekly meeting with execs – similar to a stand-up meeting – where the PO communicates progress, challenges, and changes. This way the execs have some visibility into the process and can lend assistance in addressing challenges early and often. This will also increase the executives’ trust in the PO and the Agile process.
If we have a fixed budget and a deadline. How do I effectively manage scope so that we have something launchable on time?
Select user stories that all support a single product line or workflow. It’s better to have the release be a fully functional improvement than a bunch of unrelated stories from multiple product lines or workflows.
Part of this is to be honest about how many features you really need in order to achieve goals. Focus on the minimal set of features that make the product viable and usable (referred to as the “Minimum Viable Product” or MVP). You can go back later to buff them up.
The other part is to be disciplined and forceful with stakeholders, resisting the temptation to try to please everyone by prioritizing little pieces of everybody’s individual favorite feature set. A good way to get on the right foot is to prioritize the Epics into an absolute order.
Imagine that there is a project to improve a case management system. For this project the customer, working with the PO and and other stakeholders, has identified a number of Epics that need to be improved or created in order to make the case management system function optimally. All these things must be built for the system to work well. The Epics are listed as:
By prioritizing these epics in ranked order, the developers and rest of the team can focus on one Epic at time. Instead of doing a few stories from Epic 1 and a few from Epic 3 and some from Epic 5, the team should focus on one at a time so that a completed area of business function can be released as soon as possible.
This prioritization exercise should include all the stakeholders if possible, being revisited periodically to allow for changes if needed. But during a sprint the teams should focus on stories from the highest priority Epic.
How do I instruct the developers in the creation of features if I don’t know anything about software design?
The great thing is that you don’t have to, and the Devs really are happy to do this part. Just be clear about your goals and what you need – they will take care of the design. Tell the team what outcomes you want the product to achieve, rather than trying to articulate functional requirements.
For instance, you may have a legacy system that you have been using for intake. As you redevelop that workflow, it may be tempting to tell the developers to design the new system to look and function like the old system, because you are comfortable and familiar with it. But the old system might have collected all the info on one long screen and used a lot of “jargon”.
The user story says that you need to collect intake information in a way that reduces data errors and encourages people to complete all the optional fields. It is not appropriate to insist that the developers make it like the old one, because the UX expert on the team knows that a Wizard tool for intake that uses plain language and steps the user through 4 short pages will satisfy the story more effectively. There is no need for you to be the expert, but you need to trust and feel comfortable with the experts you have.
How can I tell if the developers are being unreasonable?
You may experience push-back from the Development Team if they are interpreting a given requirement differently than what you had envisioned. If they respond that a requirement is too large or unachievable, it’s time to have a clarifying conversation.
Ask the development team to explain the requirement to you in their own words, using business language rather than technical jargon. This will often identify where their interpretation of the requirement has diverged from your own. If developers seem unreasonable, look for these three common causes:
- They think they are not being understood
- They were surprised by something they thought was all set
- They think you are telling them how to do their job (see previous section)
These issues are avoided by having frequent contact with the Development Team and making sure everyone is in communication from within their role. For instance, it may seem like developers are being unreasonable if they say something like, “You don’t need that feature.” But it could be that what they are really saying is, “In order to get the business outcome you want, you don’t need to build the thing you are asking to build.”
Typically, these conflicts come down to a misunderstanding and can be worked out by having the Devs explain to you how your outcome will be achieved. It may be that they misunderstood the outcome you are seeking. This interaction gives you a chance to listen to their ideas and correct any misunderstandings that could be present. Developers are there to come up with the “how”; you are there to be clear about the “what”. If their “how” gets your “what” then the outcome will be success.
How can I demand a clearer explanation from engineers?
You can remove the need for having to “demand” anything during the project by working closely with the whole team and utilizing the Agile process to keep lines of communication open and smooth.
This is where the concept of Habituation shows its value. Habituation involves using the procedural scaffolding of the Agile process to allow the whole team to focus on the context and content of the work. By consistently using activities like daily standups, sprint planning, sprint review, and retrospective the circumstance of needing to demand anything is removed – you will get the information you need through the intentional use of these activities.
In the example above, where a PO feels they are not getting a straight answer from the Devs, it helps to start with the end result. Did this lack of a straight answer result in a failed story or other barrier to the team? Even if it didn’t, the feelings of miscommunication is causing bad feelings and distrust to grow within the PO. The best way to handle it is to speak to the Scrum Master and work together to find a solution. The Scrum Master may bring the issue up during a retrospective and will likely work with you and the Dev Team to remove the barrier. It’s best that the whole team be part of the solution.
How should I be transparent about potential changes?
As you receive functional components of the product, new ideas and stories will inevitably develop, which should be captured and put on a backlog. The Agile framework naturally allows for these “changes” – which are really refinements, discoveries, and improvements – to be addressed in the normal cycle.
The best way to communicate changes is in the context of the business outcomes that stakeholders are seeking. For example, one of the goals for a project may be to give customers better access to information about their case. The team decides that they need a phone line, an IVR, with a call menu tree. At first it’s decided that there should be two choices for callers:
- Press one for status of case
- Press two to open a new case
After the team develops and releases the call tree, it works so well that someone suggests adding two sub-choices under option 1:
- Press one for status of case
- Press one for cases in the south
- Press two for cases in the north
The new stories are added to the backlog. During sprint planning, it is discovered that 80% of cases are in the south, and the south is made up of 4 regions. Since the north has just one region, the options are restructured by region:
- Press one for region 1
- Press two for region 2
The Agile process demands that the PO return to stakeholders and make sure this new feature fits the bill. If it does, the PO changes the story in the backlog and it is added to the next sprint. A change of this size can be left to the PO. If the change results in a conflict that can’t be resolved without executive involvement or it risks adding significant cost, the change is escalated to be addressed in a regular meeting with execs about status, challenges and changes.
Why should I want the team to build a Minimal Viable Product (MVP)? How do I convince my stakeholders to accept this approach?
Building to the Minimum Viable Product provides early and long-term benefits to both developers and customers. Help your stakeholders and users focus on what they really need for the best business process, rather than allowing them to focus on lists of features that are difficult to achieve with MVP.
Here are the key benefits of an MVP:
- Quickly provides a working product to end users that tangibly improves their life and work
- Customers can withdraw the invested value of the effort of development right away
- Decisions about improvements can be made in a real world context
- Developers can focus on aspects of the system that bring the highest value to customers
- The organizational change of implementing a new system is less disruptive, more inclusive
- Everyone gets to practice and refine the dev-build-release process in low risk scenarios
Here is a sample storyline of how a new development project (and the concept of incremental development) is experienced in the government context.
Project Team: (at a kick off meeting) “We are going to redevelop or make a new case management system because, (reasons).”
Stakeholders: (to themselves) “Oh no.” (to the project team) “The last time we did this, woe and despair fell upon us, we never really finished it, and there are lots of things we still need.”
Project Team: “It will be different this time – we have this Agile thing we are doing.”
Stakeholders: “Okay… Here is a list of everything we ever wanted, prioritized by the stuff you guys missed last time.”
Project Team: “Actually, we want to focus on just the basic bits you really need, then after we release that, we’ll keep improving it.”
Stakeholders: “Look, if we don’t ask for everything, we will get nothing – plus, we need a full detailed plan for the grant, so this incremental approach just won’t work here.”
It is important, when talking about MVP, not to frame things in terms of what actual features will be developed. As evidenced by cable company packages and smartphones, people will spend a lot of money and time on a list of features they don’t really need, simply because a longer list feels more impressive and useful. Instead, focus the discussion on the real world workflows and scenarios users will encounter – the actions they will take and how they will use the product.
The best way to direct stakeholders’ energy into a positive circuit is to collaborate with them on how to make the business process better, and then ask the questions:
“What needs to change about the system to make the new business process usable?”
“What changes do we need right now, and what changes would be helpful later?”
When users have new ideas, they want to see those ideas come to life. MVP allows your team to quickly show the users how their ideas work in actuality, test and refine them, and make everyone’s life a little better in the process.
When introducing the concept of MVP, make your customers comfortable by explaining the process clearly, and give the group a chance to practice on a low-risk, high-reward deliverable, such as the IVR system example above. The team was able to convince the stakeholder to use the MVP because they targeted a real pain point, and offered a way to relieve that pain right away. They also promised to keep refining it if needed, and they kept the promise.
It is super important that everyone keep their promises. The PO, representing the customer/user, promises to keep the product as simple as possible, while the developers promise to make it only as complex as it needs to be to solve the problem.
How do I effectively manage the expectations of my various stakeholders?
Effectively managing stakeholder expectations takes strategic thinking, great communication, and lots of practice. One of the best ways to correctly set expectations from the outset is by educating your stakeholders on the product vision and the Agile process.
The Product Owner must constantly articulate the product vision — the unifying theme that all stakeholders can relate to, regardless of their specific role inside or outside the organization. In addition to the vision communicating an outline of what the product WILL be, the vision should communicate what the product WILL NOT be. This helps to keep expectations streamlined.
The Product Owner can also set correct expectations by educating stakeholders on the Agile process. Throughout the course of developing a product, it is nearly certain that plans and priorities will change. The core Agile process does not need to change. Managing expectations becomes much easier if your stakeholders can focus on and understand the process rather than focusing on specific outputs.
What should I do when things don’t go as expected?
It is expected that things won’t go as expected. The Agile methodology assumes there will be changes to the initial plan, and includes a process for dealing with these changes productively.
If the Product Owner has educated stakeholders about the Agile process and its ability to deal with change, there should not be major upheaval when things don’t go as initially expected. The process itself does not change – rather, the discussions and decisions that happen in meetings are free to reflect the current reality (rather than pretending the initial expectations have held true). This honesty allows the team to make the best decisions for improvement going forward.
If your stakeholders, boss, or team are having trouble riding the waves of change, point them back to the value of using change to create a better end product. Remind them that being Agile means being flexible.
How do I push back on high estimates from the Development Team?
The Developers are the experts on estimating the complexity and effort required to build the features described by the user story acceptance criteria. Rather than pushing back on high estimates, probe the team to better understand potential changes in the criteria that would result in lower effort.
Often the Product Owner is surprised by how high the development team’s estimates are for effort and complexity of making the product vision into reality. In that case, it is not productive for the PO to question their expertise. Instead, make sure you understand which aspects of the requirements or user story acceptance criteria are driving the effort and complexity. In many cases, the estimate can be reduced by removing high-effort, low-value acceptance criteria from the user story for that feature.