Tag: complexity

You go to see a movie with a friend. You sit side-by-side and watch the same movie projected on the screen. Afterward, in discussing the movie, you both disagree on the motives of the lead character and even quibble over the sequence of events in the movie you just watched together.

How is it that two people having just watched the same movie could come to different conclusions and even disagree over the sequence of events that – objectively speaking – could have only happened in one way?

It’s what brains do. Memory is imperfect and every one of us has a unique set of filters and lenses through which we view the world. At best, we have a mostly useful but distorted model of the world around us. Not everyone understands this. Perhaps most people don’t understand this. It’s far more common for people – especially smart people – to believe and behave as if their model of the world is 1) accurate and 2) shared with everybody else on the planet.

Which gets me to the notion of the user manuals we all carry around in our heads about OTHER people.

Imagine a tall stack of books, some thin others very thick. On the spine of each book is the name of someone you know. The book with your partner’s name on it is particularly thick. The book with the name of your favorite barista on the spine is quite a bit thinner. Each of these books represents a manual that you have written on how the other person is supposed to behave. Your partner, for example, should know what they’re supposed to be doing to seamlessly match your model of the world. And when they don’t follow the manual, there can be hell to pay.

Same for your coworkers, other family members, even acquaintances. The manual is right there in plain sight in your head. How could they not know that they’re supposed to return your phone call within 30 minutes? It’s right there in the manual!

It seems cartoonish. But play with this point of view for a few days. Notice how many things – both positive and negative – you project onto others that are based on your version of how they should be behaving. What expectations do you have, based on the manual you wrote, for how they’re supposed to behave?

Now ask yourself, in that big stack of manuals you’ve authored for how others’ brains should work, where is your manual? If you want to improve all your relationships, toss out all of those manuals and keep only one. The one with your name on the spine. Now focus on improving that one manual.

In a recent conversation with colleagues we were debating the merits of using story point velocity as a metric for team performance and, more specifically, how it relates to determining a team’s predictability. That is to say, how reliable the team is at completing the work they have promised to complete. At one point, the question of what is a story point came up and we hit on the idea of story points not being “points” at all. Rather, they are more like currency. This solved a number of issues for us.

First, it interrupts the all too common assumption that story points (and by extension, velocities) can be compared between teams. Experienced scrum practitioners know this isn’t true and that nothing good can come from normalizing story points and sprint velocities between teams. And yet this is something non-agile savvy management types are want to do. Thinking of a story’s effort in terms of currency carries with it the implicit assumption that one team’s “dollars” are not another team’s “rubles” or another teams “euros.” At the very least, an exchange evaluation would need to occur. Nonetheless, dollars, rubles, and euros convey an agreement of value, a store of value that serves as a reliable predictor of exchange. X number of story points will deliver Y value from the product backlog.

The second thing thinking about effort as currency accomplished was to clarify the consequences of populating the product backlog with a lot of busy work or non-value adding work tasks. By reducing the value of the story currency, the measure of the level of effort becomes inflated and the ability of the story currency to function as a store of value is diminished.

There are a host of other interesting economics derived thought experiments that can be played out with this frame around story effort. What’s the effect of supply and demand on available story currency (points)? What’s the state of the currency supply (resource availability)? Is there such a thing as counterfeit story currency? If so, what’s that look like? How might this mesh with the idea of technical or dark debt?

Try this out at your next backlog refinement session (or whenever it is you plan to size story efforts): Ask the team what you would have to pay them in order to complete the work. Choose whatever measure you wish – dollars, chickens, cookies – and use that as a basis for determining the effort needed to complete the story. You might also include in the conversation the consequences to the team – using the same measures – if they do not deliver on their promise.

An experienced scrum master describes their work cycles as going “from being very busy during sprint end/start weeks to be [sic] very bored.” While this scrum master works very hard to fill in the gaps with 1:1’s with the team members and providing regular training opportunities, they nonetheless ask the question, “Does anyone have any suggestions of things I am maybe not doing that I should be doing?” One response included the following:

“Now, it could be that you have worked to create a hyper-performing team and there is no further room for improvement. A measure of this is that velocity (or similar metric) has increased by an order of magnitude in the last year.

However, the most likely scenario is that you and your team have become ‘comfortable’ and velocity has not increased significantly in the last few Sprints and/or there is a high variance in velocity.”

This reflects a common misunderstanding of “velocity” and its confusion with “acceleration.” (It also reflects the “more is better” and “winners vs losers” thinking derived from the scrum sports metaphor and points as a way of keeping score. I’ve written about that elsewhere.) Neither does the commenter understand what “order of magnitude” means. A velocity that increases by an order of magnitude in a year isn’t a velocity, it’s an acceleration. That’s a bad thing. This wouldn’t be a “hyper-performing” team. This would be a team headed for a crash as a continual acceleration in story points completed is untenable. More and more points each sprint isn’t the goal of scrum. A product owner cannot predict when their team might complete a feature or a project if the delivery of work is accelerating throughout the project.

Assuming a typical project, something that continues for a year or more, the team and the project will eventually crash as they’ve been pressured to work more and more hours and cut more and more corners in the interests of completing more and more points. The accumulation of bugs, small and large, will slow progress. Team fatigue will increase and moral decrease, resulting in turn-over and further delays. In common parlance, this is referred to as a “death march.”

Strictly speaking, velocity is some displacement over time. In the case of scrum, it is the number of story points completed in a sprint. We’ve “displace” some number of story points from being “not done” to “done.” By itself, a single sprint’s velocity isn’t particularly useful. Looking at the velocity of a number of successive sprints, however, is useful. There are two pieces of information from looking at successive sprint velocities that, when considered together, can reveal useful aspects of how well a team is performing or not. The first is the average over the previous 5 to 8 sprints, a rolling average. As a yard stick, this can provide a measure of predictability. Using this average, a product owner can make a rough calculation for how many sprints remain before completing components or the project based on the story point information in the product backlog.

The measure of confidence for this prediction would come from an analysis of the variance demonstrated in the sprint velocity values over time. Figures 1 and 2 show the distinction between the value provided by a rolling average and the value provided by the variance in values over time.

Figure 1

Figure 2

In both cases the respective teams have an average velocity of 21 points per sprint. However, the variability in the values over time show that the team in Figure 1 would have a much higher level of confidence in any predictions based on their past performance than the team shown in Figure 2.

What matters is the trend, each sprint’s velocity over a number of sprints. The steady completion of story points (i.e. work) sprint to sprint is the desirable goal. Another way to say this is that a steady velocity makes it possible to predict project delivery dates. In real life, there will be a variance (up and down) of sprint velocity over time and the goal is to guide the project such that this variance is within a manageable range.

If a team were to set as its goal an increase in the number of story points completed from sprint to sprint then their performance chart might initially look like Figure 3.

Figure 3

Such a pace is unsustainable and eventually the team burns out. Fatigue, decreased moral, and overall dissatisfaction with the project cause team members to quit and progress grinds to a halt. The fallout of such a collapse is likely to include the buildup of significant technical debt and code errors as the run-up to the crescendo forced team members to cut corners, take shortcuts, and otherwise compromise the quality of their effort. [1] The resulting performance chart would look something like Figure 4.

Figure 4

All that said, I grant that there is merit in coaching teams to make reasonable improvements in their overall sprint performance. An increase in the overall average velocity might be one way to measure this. However, to press the team into achieving an order of magnitude increase in performance is a fools errand and more than likely to end in disaster for the team and the project.

It appears mindfulness is…well…on a lot ofpeople’smindslately. I’ve seen this wave come and go twice before. This go around, however, will be propelled and amplified be the Internet. Will it come and go faster? Will there be a lasting and deeper revelation around mindfulness? I predict the former.

Mindfulness is simple and it’s hard. As the saying goes, mindfulness is not what you think. It was difficult when I first began practicing Rinzai Zen meditation and Aikido many years ago. It’s even more difficult in today’s instant information, instant gratification, and short attention span culture. The uninitiated are ill equipped for the journey.

With this latest mindfulness resurgence expect an amplified parasite wave of meditation teachers and mindfulness coaches. A Japanese Zen Master (Roshi, or “teacher”) I studied with years ago called them “popcorn roshis” – they pop up everywhere and have little substance. No surprise that this wave includes a plethora of mindfulness “popcorn apps.”

Spoiler alert: There are no apps for mindfulness. Attempting to develop mindfulness by using an app on a device that is arguably the single greatest disruptor of mindfulness is much like taking a pill to counteract the side effects of another pill in your quest for health. At a certain point, the pills are the problem. They’ve become the barrier to health.

The “mindfulness” apps that can be found look to be no different than thousands of other non-mindfulness apps offering timers, journaling, topical text, and progress tracking. What they all have in common is that they place your mindfulness practice in the same space as all the other mindfulness killing apps competing for your attention – email, phone, texts, social media, meeting reminders, battery low alarms, and all the other widgets that beep, ring, and buzz.

The way to practicing mindfulness is by the deliberate subtraction of distractions, not the addition of another collection of e-pills. The “killer app” for mindfulness is to kill the app. The act of powering off your smart phone for 30 minutes a day is in itself a powerful practice toward mindfulness. No timer needed. No reminder required. Let it be a random act. Be free! At least for 30 minutes or so.

Mental states like mindfulness, focus, and awareness are choices and don’t arise out of some serendipitous environmental convergence of whatever. They are uniquely human states. Relying on a device or machine to develop mindfulness is decidedly antithetical to the very state of mindfulness. Choosing to develop such mental states requires high quality mentors (I’ve had many) and deliberate practice – a practice that involves subtracting the things from your daily life that work against them.

“For if a person shifts their caution to their own reasoned choices and the acts of those choices, they will at the same time gain the will to avoid, but if they shift their caution away from their own reasoned choices to things not under their control, seeking to avoid what is controlled by others, they will then be agitated, fearful, and unstable.” – Epictetus, Discourses, 2.1.12

Related Posts

Somewhere along the path of studying Aikido for 25 years I found a useful perspective on the art that applies to a lot of skills in life. Aikido is easy to understand. It’s a way of living that leaves behind it a trail of techniques. What’s hard is overcoming the unending stream of little frustrations and often self-imposed limitations. What’s hard is learning how to make getting up part of falling down. What’s hard is healing after getting hurt. What’s hard is learning the importance of recognizing when a white belt is more of a master than you are. In short, what’s hard is mastering the art.

The same can be said about practicing Agile. Agile is easy to understand. It is four fundamental values and twelve principles. The rest is just a trail of techniques and supporting tools – rapid application development, XP, scrum, Kanban, Lean, SAFe, TDD, BDD, stories, sprints, stand-ups – all just variations from a very simple foundation and adapted to meet the prevailing circumstances. Learning how to apply the best technique for a given situation is learned by walking the path toward mastery – working through the endless stream of frustrations and limitations, learning how to make failing part of succeeding, recognizing when you’re not the smartest person in the room, and learning how to heal after getting hurt.

If an Aikidoka is attempting to apply a particular technique to an opponent and it isn’t working, their choices are to change how they’re performing the technique, change the technique, or invent a new technique based on the fundamentals. Expecting the world to adapt to how you think it should go is a fool’s path. Opponents in life – whether real people, ideas, or situations – are notoriously uncompromising in this regard. The laws of physics, as they say, don’t much care about what’s going on inside your skull. They stubbornly refuse to accommodate your beliefs about how things “should” go.

The same applies to Agile practices. If something doesn’t seem to be working, it’s time to step in front of the Agile mirror and ask yourself a few questions. What is it about the fundamentals you’re not paying attention to? Which of the values are out of balance? What technique is being misapplied? What different technique will better serve? If your team or organization needs to practice Lean ScrumXPban SAFe-ly than do that. Be bold in your quest to find what works best for your team. The hue and cry you hear won’t be from the gods, only those who think they are – mere mortals more intent on ossifying Agile as policy, preserving their status, or preventing the perceived corruption of their legacy.

But I’m getting ahead of things. Before you can competently discern which practices a situation needs and how to best structure them you must know the fundamentals.

There are no shortcuts.

In this series of posts I hope to open a dialog about mastering Agile practices. We’ll begin by studying several maps that have been created over time that describe the path toward mastery, discuss the benefits and shortcomings of each of these maps, and explore the reasons why many people have a difficult time following these maps. From there we’ll move into the fundamentals of Agile practices and see how a solid understanding of these fundamentals can be used to respond to a wide variety of situations and contexts. Along the way we’ll discover how to develop an Agile mindset.

The scrum framework is forever tied to the language of sports in general and rugby in particular. We organize our project work around goals, sprints, points, and daily scrums. An unfortunate consequence of organizing projects around a sports metaphor is that the language of gaming ends up driving behavior. For example, people have a natural inclination to associate the idea of story points to a measure of success rather than an indicator of the effort required to complete the story. The more points you have, the more successful you are. This is reflected in an actual quote from a retrospective on things a team did well:

We completed the highest number of points in this sprint than in any other sprint so far.

This was a team that lost sight of the fact they were the only team on the field. They were certain to be the winning team. They were also destine to be he losing team. They were focused on story point acceleration rather than a constant, predictable velocity.

More and more I’m finding less and less value in using story points as an indicator for level of effort estimation. If Atlassian made it easy to change the label on JIRA’s story point field, I’d change it to “Fuzzy Bunnies” just to drive this idea home. You don’t want more and more fuzzy bunnies, you want no more than the number you can commit to taking care of in a certain span of time typically referred to as a “sprint.” A team that decides to take on the care and feeding of 50 fuzzy bunnies over the next two weeks but has demonstrated – sprint after sprint – they can only keep 25 alive is going to lose a lot of fuzzy bunnies over the course of the project.

It is difficult for people new to scrum or Agile to grasp the purpose behind an abstract idea like story points. Consequently, they are unskilled in how to use them as a measure of performance and improvement. Developing this skill can take considerable time and effort. The care and feeding of fuzzy bunnies, however, they get. Particularly with teams that include non-technical domains of expertise, such as content development or learning strategy.

A note here for scrum masters. Unless you want to exchange your scrum master stripes for a saddle and spurs, be wary of your team turning story pointing into an animal farm. Sizing story cards to match the exact size and temperament from all manner of animals would be just as cumbersome as the sporting method of story points. So, watch where you throw your rope, Agile cowboys and cowgirls.

Conceptually, the idea of a minimum viable product (MVP) is easy to grasp. Early in a project, it’s a deliverable that reflects some semblance to the final product such that it’s barely able to stand on it’s own without lots of hand-holding and explanation for the customer’s benefit. In short, it’s terrible, buggy, and unstable. By design, MVPs lack features that may eventually prove to be essential to the final product. And we deliberately show the MVP to the customer!

We do this because the MVP is the engine that turns the build-measure-learn feedback loop. The key here is the “learn” phase. The essential features to the final product are often unclear or even unknown early in a project. Furthermore, they are largely undefinable or unknowable without multiple iterations through the build-measure-learn feedback cycle with the customer early in the process.

So early MVPs aren’t very good. They’re also not very expensive. This, too, is by design because an MVP’s very raison d’être is to test the assumptions we make early on in a project. They are low budget experiments that follow from a simple strategy:

State the good faith assumptions about what the customer wants and needs.

Describe the tests the MVP will satisfy that are capable of measuring the MVP’s impact on the stated assumptions.

Build an MVP that tests the assumptions.

Evaluate the results.

If the assumptions are not stated and the tests are vague, the MVP will fail to achieve it’s purpose and will likely result in wasted effort.

The “product” in “minimum viable product” can be almost anything: a partial or early design flow, a wireframe, a collection of simulated email exchanges, the outline to a user guide, a static screen mock-up, a shell of screen panels with placeholder text that can nonetheless be navigated – anything that can be placed in front of a customer for feedback qualifies as an MVP. In other words, a sprint can contain multiple MVPs depending on the functional groups involved with the sprint and the maturity of the project. As the project progresses, the individual functional group MVPs will begin to integrate and converge on larger and more refined MVPs, each gaining in stability and quality.

MVPs are not an end unto themselves. They are tangible evidence of the development process in action. The practice of iteratively developing MVPs helps develop to skill of rapid evaluation and learning among product owners and agile delivery team members. A buggy, unstable, ugly, bloated, or poorly worded MVP is only a problem if it’s put forward as the final product. The driving goal behind iterative MVPs is not perfection, rather it is to support the process of learning what needs to be developed for the optimal solution that solves the customer’s problems.

“Unlike a prototype or concept test, an MVP is designed not just to answer product design or technical questions. Its goal is to test fundamental business hypotheses.” – Eric Ries, The Lean Startup

So how might product owners and Agile teams begin to get a handle on defining an MVP? There are several questions the product owner and team can ask of themselves, in light of the product backlog, that may help guide their focus and decisions. (Use of the following term “stakeholders” can mean company executives or external customers.)

Identify the likely set of stakeholders who will be attending the sprint review. What will these stakeholders need to see so that they can offer valuable feedback? What does the team need to show in order to spark the most valuable feedback from the stakeholders?

What expectations have been set for the stakeholders?

Is the distinction clear between what the stakeholders want vs what they need?

Is the distinction clear between high and low value? Is the design cart before the value horse?

What are the top two features or functions the stakeholders will be expecting to see? What value – to the stakeholders – will these features or functions deliver?

Will the identified features or functions provide long term value or do they risk generating significant rework down the road?

Are the identified features or functions leveraging code, content, or UI/UX reuse?

Recognizing an MVP – Less is More

Since an MVP can be almost anything, it is perhaps easier to begin any conversation about MVPs by touching on the elements missing from an MVP.

An MVP is not a quality product. Using any generally accepted definition of “quality” in the marketplace, an MVP will fail on all accounts. Well, on most accounts. The key is to consider relative quality. At the beginning of a sprint, the standards of quality for an MVP are framed by the sprint goals and objectives. If it meets those goals, the team has successfully created a quality MVP. If measured against the external marketplace or the quality expectations of the customer, the MVP will almost assuredly fail inspection.

Your MVPs will probably be ugly, especially at first. They will be missing features. They will be unstable. Build them anyway. Put them in front of the customer for feedback. Learn. And move on to the next MVP. Progressively, they will begin to converge on the final product that is of high quality in the eyes of the customer. MVPs are the stepping stones that get you across the development stream and to the other side where all is sunny, beautiful, and stable. (For more information on avoiding the trap of presupposing what a customer means by quality and value, see “The Value of ‘Good Enough’“)

An MVP is not permanent. Agile teams should expect to throw away several, maybe even many, MVPs on their way to the final product. If they aren’t, then it is probable they are not learning what they need to about what the customer actually wants. In this respect, waste can be a good, even important thing. The driving purpose of the MVP is to rapidly develop the team’s understanding of what the customer needs, the problems they are expecting to have solved, and the level of quality necessary to satisfy each of these goals.

MVPs are not the truth. They are experiments meant to get the team to the truth. By virtue of their low-quality, low-cost nature, MVPs quickly shake out the attributes to the solution the customer cares about and wants. The solid empirical foundation they provide is orders of magnitude more valuable to the Agile team than any amount of speculative strategy planning or theoretical posturing.

Do you see white dots embedded within the grid connected by diagonal white lines? If you do, try and ignore them. Chances are, your brain won’t let you even though the white circles and diagonal lines don’t exist. Their “thereness” is created by the thin black lines. By carefully drawing a simple repetitive pattern of black lines, your brain has filled in the void and enhanced the image with white dots and diagonal white lines. You cannot not do this. This cognitive process is important to be aware of if you are a product owner because both your agile delivery team members and clients will run this program without fail.

Think of the black lines as the minimum viable product definition for one of your sprints. When shown to your team or your client, they will naturally fill the void for what’s next or what’s missing. Maybe as a statement, most likely as a question. But what if the product owner defined the minimum viable product further and presented, metaphorically, something like this:

By removing the white space from the original image there are fewer possibilities for your team and the client to explore. We’ve reduced their response to our proposed solution to a “yes” or “no” and in doing so have started moving down the path of near endless cycles of the product owner guessing what the client wants and the agile delivery team guessing what the product owner wants. Both the client and the team will grow increasingly frustrated at the lack of progress. Played out too long, the client is likely to doubt our skills and competency at finding a solution.

On the other hand, by strategically limiting the information presented in the minimum viable product (or effort, if you like) we invite the client and the agile delivery team to explore the white space. This will make them co-creators of the solution and more fully invested in its success. Since they co-created the solution, they are much more likely to view the solution as brilliant, perfect, and the shiniest of shiny objects.

I can’t remember where I heard or read this, but in the first image the idea is that the black lines are you talking and the white spaces are you listening.

When my experience with scrum began to transition from developer to scrum master and on to mentor and coach, early frustrations could have been summed up in the phrase, “Why can’t people just follow a simple framework?” The passage of time and considerable experience has greatly informed my understanding of what may inhibit or prevent intelligent and capable people from picking up and applying a straightforward framework like scrum.

At the top of this list of insights has to be the tendency of practitioners to place elaborate decorations around their understanding of scrum. In doing so, they make scrum practices less accessible. The framework itself can make this a challenge. Early on, while serving in the role of mentor, I would introduce scrum with an almost clinical textbook approach: define the terms, describe the process, and show the obligatory recursive work flow diagrams. In short order, I’d be treading water (barely) in endlessly circuitous debates on topics like the differences between epics and stories. I wrote about this phenomenon in a previous post as it relates to story points. So how can we avoid being captured by Parkinson’s law of triviality and other cognitive traps?

Words Matter

I discovered that the word “epic” brought forth fatigue inducing memories of Homer’s Iliad and Odyssey, the Epic of Gilgamesh, and Shakespeare. Instant block. Solution out of reach. It was like putting a priceless, gold-plated, antique picture frame around the picture postcard of a jackalope your cousin Eddie sent you on his way through Wyoming. Supertanker loads of precious time were wasted in endless debates about whether or not something was an epic or a story. So, no more talk of epics. I started calling them “story categories.” Or “chapters.” Or “story bundles.” Whatever it took to get teams onto the idea that “epics” are just one of the dimensions to a story map or product backlog that helps the product owner and agile delivery team keep a sense of overall project scope. Story writing progress accelerated and teams were doing a decent job of creating “epics” without knowing they had done so. Fine tuning their understanding and use of formal scrum epics came later and with much greater ease.

“Sprint” is another unfortunate word in formal scrum. With few exceptions, the people that have been on my numerous scrum teams haven’t sprinted anywhere in decades. Sprinting is something one watches televised from some far away place every four years. Maybe. Given its fundamental tenets and principles, who’s to say a team can’t find a word for the concept of a “sprint” that makes sense to them. The salient rule, it would seem, is that whatever word they choose, the team fully understand that “it” is a time-boxed commitment for completing a defined set of work tasks. And if “tide,” “phase,” or “iteration” gets the team successfully through a project using scrum than who am I to wear a the badge of “Language Police?”

A good coach meets the novice at their level and then builds their expertise over time, structured in a way that matches and challenges the learner’s capacity to learn. I recall from my early Aikido practice the marked difference between instructors who stressed using the correct Japanese name for a technique over those that focused more on learning the physical techniques and described them in a language I could understand. Once I’d learned the physical patterns the verbal names came much more easily.

Full disclosure: this is not as easy when there are multiple scrum teams in the same organization that eventually rotate team members. Similarly, integrating new hires with scrum experience is much easier when the language is shared. But to start, if the block to familiarization with the scrum process revolves around semantic debates it makes sense to adapt the words so that the team can adopt the process then evolve the words to match more closely those reflected in the scrum framework.

Philosophy, System, Mindset, or Process

A similar fate awaited team members that had latched onto the idea that scrum or agile in general is a philosophy. I watched something similar happen in the late 1980’s when the tools and techniques of total quality management evolved into monolithic world views and corporate religions. More recently, I’ve attended meet-ups where conversations about “What is Agile?” include describing the scrum master as “therapist” or “spiritual guide.” Yikes! That’s some pretty significant mission creep.

I’m certain fields like philosophy and psychotherapy could benefit from many of the principles and practices found in agile. But it would be a significant category error to place agile at the same level as those fields of study. If you think tasking an agile novice with writing an “epic” is daunting, try telling them they will need to study and fully understand the “philosophy of agile” before they become good agile practitioners.

The issue is that it puts the idea of practicing agile essentially out of reach for the new practitioner or business leader thinking about adopting agile. The furthest up this scale I’m willing to push agile is that it is a mindset. An adaptive way of thinking about how work gets done. From this frame I can leverage a wide variety of common, real-life experiences that will help those new to agile understand how it can help them succeed in their work life.

Out in the wild, best to work the system and process angles if you want meaningful work to actually get done.

Parkinson observed and illustrated that a committee whose job was to approve plans for a nuclear power plant spent the majority of its time on discussions about relatively trivial and unimportant but easy-to-grasp issues, such as what materials to use for the staff bike-shed, while neglecting the non-trivial proposed design of the nuclear power plant itself, which is far more important but also a far more difficult and complex task to criticise constructively.

I see this phenomenon in play during team story sizing exercises in the following scenarios.

In the context of the story being sized, the relative expertise of each of the team members is close to equal in terms of experience and depth of knowledge. The assumption is that if everyone on the team is equally qualified to estimate the effort and complexity of a particular story then the estimation process should move along quickly. With a skilled team, this does, indeed, occur. If it is a newly formed team or if the team is new to agile principles and practices, Parkinson’s Law of Triviality can come into play as the effort quickly gets lost in the weeds.

In the context of the story being sized, the relative expertise of the team members is not near parity and yet each of the individual team members has a great deal of expertise in the context of their respective functional areas. What I’ve observed happening is that the team members least qualified to evaluate the particular story feel the need to assert their expertise and express an opinion. I recall an instance where a software developer estimated it would take 8 hours of coding work to place a “Print This” button on a particular screen. The credentialed learning strategist (who asked for the print button and has no coding experience) seemed incredulous that such an effort would require so much time. A lengthy and unproductive argument ensued.

To prevent this I focus my coaching efforts primarily on the product owner as they will be interacting with the team on this effort during product backlog refinement session more frequently than I. They need to watch for:

Strong emotional response by team members when a size or time estimate is proposed.

Conversations that drop further and further into design details.

Conversations that begin to explore multiple “what if” scenarios.

The point isn’t to prevent each of these behaviors from occurring. Rather manage them. If there is a strong emotional response, quickly get to the “why” behind that response. Does the team member have a legitimate objection or does their response lack foundation?

Every team meeting is an opportunity to clarify the bigger picture for the team so a little bit of conversation around design and risks is a good thing. It’s important to time box those conversations and agree to take the conversation off-line from the backlog refinement session.

When coaching the team, I focus primarily on the skills needed to effectively size an effort. Within this context I can also address the issue of relative expertise and how to leverage and value the opinions expressed by team member who may not entirely understand the skill needed to complete a particular story.

(John Cook cites another interesting example of Parkinson’s Law of Triviality (a.k.a. the bike shed principle) from Michael Beirut’s book How to involving the design of several logos.)