Articles about Technology

Many organizations struggle to adopt Agile as part of their digital transformation. And one of the most common struggles in adopting Agile is how to move toward incremental and iterative refinement. Iterating on a goal allows more information to be gained quickly, but it also means timelines are likely to overlap. While stakeholders tend to focus on their piece of the puzzle or the next goal, product owners have to balance complex timelines and goals for multiple stakeholders. How does an Agile product owner prioritize all the overlapping timelines and goals within the wider context of their organization? There are no solid rules, and everyone has to adapt to their own organization, but many successful product owners factor in the following key principles to make their decisions and plan their sprints: Prioritize based on a mixture of urgency, importance, and size Use tactical stories to achieve strategic goals Find ways to regularly invest in maintenance These principles can increase product ownership success and even lead to greater agile adoption across your organization. As in most things, the trick is balance. Prioritize stories based on Urgency, Importance, and Size Urgency There is always pressure to prioritize urgency. You can’t turn back time, and if you miss an urgent issue then you are certain to hear about it. However, the biggest mistake product owners make is prioritizing urgency too high. There will always be urgent requests, and if urgency is your only factor, you will only end up fulfilling urgent requests. Importance Importance is not always reflected in urgency, but it must always be reflected in priority. Waiting for important work to also become urgent almost certainly spells disaster. The proactive stance of prioritizing important work against urgent work also tends to have political implications. We’ve all heard the adage “the squeaky wheel gets the grease.” The best customers are typically the ones who complain the least, so don’t punish them for that. This also applies to stakeholders. The more you incentivize good stakeholder behavior, the more you are in control of your backlog. Size Of course, urgency and importance are not the only two factors to balance. Part of the difficulty of building a sprint for a product owner is the need to also balance size. Ideally, you want constant progress throughout a sprint. It is common for a feature to get started and then get blocked. That is why you need to include user stories of all sizes. Only having large stories tends to mean stories will get handed off mid-sprint. Knowledge sharing provides value, but mid-sprint handoff only slows progress. If most stories in your backlog tend to be large, small stories will have increased priority in order to fill in a sprint even though they may be of lower importance and only medium urgency. Prioritizing through a mix of urgency, importance, and size doesn’t just create a balanced sprint, it also creates a balanced time orientation. Urgent stories make a team reactive. You can’t look forward when you’re focusing on past mistakes or present pressure. Directing your team’s time orientation beyond the present moment is a key strategy for creating a productive team. Use tactical stories to achieve strategic goals Of course, not every sprint can be a perfect balance of importance, urgency, and size. Like the strategy for directing a team’s time orientation, some choices might be preferred to create or enforce a team culture. While a product owner is the leader of their team, they also answer to stakeholders. And organization objectives, usually data-driven ones, are created with these stakeholders as part of an organizational strategy. The decisions a product owner makes that have a direct impact on reaching these objectives are called tactics. But the product owner is still leading a team! There are many strategic decisions that a product owner makes which may not have a direct benefit to organizational objectives, however, they might lead to a more productive team. Good product owners don’t just focus on tactical decisions of meeting objectives, they refine strategies that benefit the individual team and drive toward objectives in an indirect manner. For instance, retrospectives tend to generate more strategic shifts than tactical shifts. Common examples of tactics used by product owners: Sprints containing stories of varying size Proof of Concept (POC) stories which discover information to do further planning or design Prioritizing the most complex use cases first Prioritizing the most common use cases first Stories that require liaising with other teams, when collaboration is an organizational goal Maintenance which offers innovation affordances Maintenance which increases product stability Common examples of product owner strategies: Cross-training by assigning stories based on areas of weakness Siloing specialties so individuals achieve high efficiency in strategic skills Requiring recorded demos as acceptance criteria for certain stakeholders Requiring regular alpha or beta releases for highly engaged stakeholders to provide feedback “Dead sprints” following releases which allow for feedback to build before addressing it Documentation stories which seek to identify outdated/deprecated documentation and update it in order to lower future bug counts Support buckets, allocated time for bugfixes that can be released ad-hoc instead of on a sprint schedule To clarify, I am not recommending that product owners devote large amounts of resources to tasks which in no way benefit organization objectives. It’s simply a recognition that indirect benefits to objectives lead to success in certain types of organizations. Strategic stories are an intentional investment in greater future value (such as cross-training), although it’s likely that the story could provide a more immediate value to the organization as well. Find ways to regularly invest in maintenance The last key principle faced by new product owners is learning how to please stakeholders while still investing in maintenance. This can sometimes be a challenge because many product owners will get a slap on the wrist if they spend too much time or money on maintenance, and not all maintenance plays are equal. However, I always recommend a portion of each sprint is dedicated to maintenance. There are different types of maintenance, so be sure to find the maintenance tactics that fit your organization’s needs. I’ll highlight a few valuable maintenance story types that have proven effective time after time. Tests Tests almost always are a valuable play. Even for a product that truly requires a higher caliber of quality — where testing is likely a requirement of the product delivery — it is common to discover there are things that lack regular testing. Tests can mean anything from writing automated unit tests for code to walking through the onboarding process to find points of friction. Unit tests make sure untouched features aren’t broken by unrelated changes. End-to-end tests take more time to perform but ensure that the most valuable processes always work. Manual tests, popular for proofs of concept, save the time required to automate tests but take longer to perform, matching a lesser initial investment to the likelihood that something will not be tested often. Manual tests can also be more valuable than unit tests for things that constantly change since overly-specific tests tend to discover more problems with the tests than they do the thing being tested. Find testing methods that work for your product, and don’t forget that processes need tested regularly as well. Support bucket The concept of a support bucket is one of my favorite strategies. It communicates to a team that things worth building are worth maintaining. Refining products regularly shows team members their work is valuable. In cases where there is a strong bug reporting system, it is likely that the team struggles to resolve bugs as fast as they come in. A support bucket is a way to maintain a position of strength. When your team is on top of their bugs, creating a support bucket addresses incoming bugs faster and keeps them from dominating a future sprint. If bugs don’t come in as much as expected, it creates a vacuum that allows team members to define their own work. Many developers relish the opportunity to take two days to refactor code that works but is confusing. However, this is something that can only be done when there are already good tests to ensure it doesn’t cause more problems than it solves. Pre-emptive customer engagement One of the least-used but highest-value maintenance tasks is pre-emptive customer engagement. If bug reports aren’t coming in, that can mean you’ve created a high-quality product! It can also mean you aren’t hearing about difficulties encountered by customers, or customers aren’t adopting product updates for some reason. When user stories are created, it is probably easy to identify real customers to whom this user story will apply. Talk to those customers and ask them how they are using the new features. How to prioritize user stories in Agile All the talk about priority, strategy, tactics, and maintenance is great, but how do I balance ALL of that when assembling a sprint? Much of this depends on the leadership and the number of stakeholders you’re dealing with. Organizational politics can send blue-sky planning into a tailspin. In the real world, you have to not only do good work, but make sure that work gets seen by the right people, and that they are impressed. If your organization’s leadership prioritizes innovation and “shiny things” This is a sign that part of your work is about the ideas and the culture shift. This is a completely valid position for a leader. There are many political advantages to trying new things and building a culture of innovation. It is a great way to gather information for refining organizational strategy. In cases like these, the following breakdown of average sprints works well: 50% strategies of short-term investment that can get thrown out or create a culture of innovation 25% tactics supporting a long-term organizational strategy 25% maintenance Applicable tactics/strategies: POCs, specialized efficiency, regular alpha/beta releases, prioritizing common use cases first, maintenance offering innovation affordances If your organization’s leadership prioritizes long-term strategy, stability or predictable growth This is a sign that part of your job is about giving customers confidence in your products. This is not an anti-innovation position, rather it is a recognition that you are in a position of strength in your market. In cases like these, the following breakdown of average sprints works well: 50% tactics supporting a long-term organizational strategy 25% strategies to shape the team 25% maintenance Applicable tactics/strategies: cross-training, prioritizing most complex use cases first, maintenance improving product stability, improving documentation, support buckets, external liaisons Closing If you’re a product owner or your organization is beginning to adopt Agile, take a look at your organization to find out what your stakeholders truly care about. While every organization is unique, these factors are universal. Tailor your strategies to your team and your tactics to your objectives. Most of all, create balanced sprints which deliver constant progress toward your goals. Analyzing urgency, importance, and size can lead to solid prioritization that drives team success.