The relationship between product owners and developers sometimes feels like an arranged marriage. Communication and building trust is essential to make it work. Let's dive a bit deeper into prioritisation and estimation as they are often the interaction points with most friction.
Product owners and developers respectively dread prioritisation and estimation because we don't tend to deal well with decisions under uncertainty. As a Scrum Master, you should build empathy by pointing out that both teams have to deal with similar problems and cultivate an environment where failure is accepted. Mistakes when deciding under uncertainty are not an if but a when and your team will feel less paralyzed with a culture that replaces blame by self-improvement. Let's go over some tips and tricks that you can teach.
Estimations
Use the whole team. While estimations provide essential input to planning, their biggest benefit lies in alignment and knowledge sharing between developers. When you poker estimate, you will sporadically see widely deviating numbers. These deviations exist because of misinterpreted requirements, hidden complexities or little-known libraries that trivialise the problem. Just realise the lost opportunity when only the senior few are involved.
Use story points. New teams can start estimating in days but should move towards story points as soon as possible (i.e. once you have a decent baseline). The disconnect between your most senior and junior developer is simply too large. The danger is that the team will unconsciously start estimating tasks for the person who is expected to do the work. Quite dangerous as these per-person sprint backlogs annihilate teamwork.
Use ballpark estimations. Ballparks are rough estimations that enable early prioritisation with low time investment. It solves the chicken and egg problem where a product owner might feel he needs estimations to prioritise while developers feel they need prioritisation to estimate. Though be explicit about it being a ballpark to avoid miscommunication down the line.
Use granular tasks. Estimations of single tasks can be widely inaccurate. But when you look at the sum of all estimations the error margin decreases as over- and underestimations cancel each other. On top of that, simply the act of splitting work into granular tasks will uncover additional information and dependencies.
Never trust third-party software providers. Spike their API or use PERT with a high pessimistic estimate.
Prioritisation
Use strategy. Have you ever felt like you are juggling multiple initiatives simultaneously that are hard to prioritise because they vary so wildly? Your strategy should focus on specific areas of the solution space. Take a step backwards from execution and revisit the current strategy. I like how Shreyas Doshi talks about Systematic Planning where each key theme receives an investment allocation. Be sure to read his inspiring Twitter thread.
Use goals. The newly released 2020 Scrum Guide doubles down on commitments. Often misunderstood is that you don't commit to a Product and Sprint Backlog but respectively to a Product and Sprint Goal. You can compromise on work as long as you progress towards your goal. Despite best intentions, roadmaps often change teams from goal- to feature-driven and in worst cases contain a fixed list of features with due dates which are communicated to customers. Instead explore quarterly objectives and key results to keep scope flexible and create alignment between managers and frontline engineers.
Use double backlog prioritisation. You want to prioritise your backlog by value, but reality forces you to account for contracts, availability of externals, hard dependencies, etc. Start by prioritising the backlog in an "unreasonable" way where this product is the single most important initiative in the industry. Afterwards make a list of impediments for anything that stands in the way. Finally, involve the team in a second prioritisation of the backlog. Find solutions to the impediments and if absolutely necessary change priorities. The conclusion should more often than not be that you can resolve these impediments. (Lyssa Adkins)
Use intuition. It worked for Instagram, it will work for you. Data-informed decisions beat data-driven decisions. There will always be room for user and A/B testing, though avoid delaying decisions as the results are often nuanced, undecisive and arrive too late.
Wrapping up
Estimation and prioritisation are difficult yet essential to well-oiled Scrum teams. Success stems from a goal-driven culture which accepts failure. As developers and product owners improve their estimation and prioritisation process, communication will improve, boundaries will fade and collaboration starts to flourish.
