April 23, 2014

All Posts In Category: Agile Coaching

Agile Coaching Blog

Stay Hungry. Stay Foolish. And Don’t Be Afraid to Say “Our Process Has No Clothes!”

“Stay hungry. Stay foolish.” Many people remember those words as a quote from Steve Jobs made during Jobs’ Stanford commencement address in 2005, where, among other things, he spoke about the Whole Earth Catalog as the Google of that day.  Referring to the Whole Earth Catalog, and that particular time in history, brings a tear to my eye and makes me smile at the same time.

People remember the four words as Jobs’, but forget that Jobs readily admitted that he didn’t make up those words – he was quoting the farewell message on the back cover of the last issue of Whole Earth Catalog in 1974.

Blog pic 1 - Stay Hungry
To this day, whenever I look at that photo, I never look at it as an end of a long and winding road, but as a beginning of a journey down it.  But that’s not why I’m writing this today.  What I’m interested in writing about starts with this “Stay hungry.  Stay foolish.” mantra, and leads us down the road of why this is so important for agility.

Staying hungry: we are reminded to focus on delighting our customer.  Hunger is so low on the Maslovian scale that it’s a basis for just about everything else.  While one item to be hungry for are the products we produce, the capital that they provide should not be considered the goal of existence.  In a sense, rather than simply dining well on the money that revenue produces, we have to also use it to plant the seeds for future revenues and the capital that it will provide.

“A rising tide lifts all boats.” It’s a phrase commonly attributed to John F. Kennedy, but he didn’t make up those words either.  He got them from a chamber of commerce called the New England Council.  For purposes here, remember that simply doing what’s worked in the past is merely a way to slowly drain the lake.  Constantly improving is what we have to do to make the lake larger. Continuous improvement doesn’t come with a checklist of things to do.  It requires creativity to figure out how to make what’s good now even better, and that requires that we never grow complacent and rest on our laurels.  We have to constantly be searching and never forgetting that things could always be even better than they are. “Curiosity is stimulated when individuals feel deprived of information and wish to reduce or eliminate their ignorance.” (The Agile Mind, p279, Wilma Koutstaal, 2012, Oxford University Press.)

Staying foolish: we are reminded to not just accept, but to question and be curious. Getting to the “whys” are far more important than just jumping to a whole bunch of “whats” (and getting them wrong the until we learn what’s really needed.)  And learning can be expensive at times.  Failure shouldn’t be viewed as a bad thing, but as something that gives us an opportunity to learn something. If nothing else, we learn what doesn’t work. As Thomas Edison said, “I have not failed. I’ve just found 10,000 ways that won’t work.” We have to be in an environment that supports that line of thought for the potential to improve through learning to work.

Sometimes the reason we fear being foolish is that the idea that we have isn’t something that we feel we should discuss.  It may be something that might make us the object of ridicule.  Maybe we’re afraid that should something go wrong, that we’ll get blamed for the failure.  Those sort of situations remind me of the old Hans Christian Andersen tale of “The Emperor’s New Clothes.”  When the vain emperor employs tailors, they decided to make clothes from a special fabric that was invisible to anyone unfit for their positions or hopelessly stupid.  The Emperor and his ministers all saw the clothes, because they feared that otherwise, they would be seen as unfit or stupid. The child who blurted out that the emperor had no clothes was not only foolish, but hungry as well (since he wasn’t part of the ruling class, who had everything to lose).  In our world, we have to find ways to be like that child if we expect to make Agile anything more than superficial self-congratulation that ultimately ends up draining the lake.  We have to make sure that in our organizations, we can stay hungry and foolish and not fear that saying “our process has no clothes” will be met with anything other than the wonderment of what’s possible.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



What’s the Right Ratio Between QA Testers and Developers?

I get asked this question all the time.  And I think that the answer is both obvious and not at the same time.  In any case, it’s not possible to answer what the ratio of developers to QA testers should be.  Here’s why.

Let’s take a look at a flowchart of how software development really occurs.

I know that there are differences in this diagram based on whether we are using “waterfall”, “Scrum”, “Kanban”, and so forth.  But the differences are usually that we don’t explicitly acknowledge the stage of process that we are in, or we subsume it in another process step.  For example, in eXtreme Programming, we tend to design, code, and functionally test all in one step. We use Unit Testing in Test Driven Development as the functional test in isolation, and the “refactor” step in “red/green/refactor” as a way to accomplish “design a solution”.

Where are the testers in that diagram?

That is, by no means, a trivial question, and it does vary based on the operating model that we use for software development.  In traditional waterfall development, we usually have testing occur by role.  Developers are typically assigned the responsibility to functionally test what they code, usually called “unit testing”.  In fact, most of what I’ve seen in the field is that those “unit tests” are usually simplified functional “spot tests” that never make it into any regression suite, rather than the eXtreme Programming type of unit tests used in Test Driven Development.  These spot tests are typically fast, throwaway, and unrepeatable.  The people in QA sometimes are called upon to do this testing.  The best that can be said is that we saw some version of code that made the code functional for its intended purpose at the point at which point the test passed.

Traditional waterfall type testing does employ QA testers at the “non-functional and regression tests” stage.  QA will typically write long test plans intended to ensure that functionality not only meets the functionality desired, but also does not have an adverse impact on either previously developed functionality or non-functional aspects of the software, such as speed, capacity, etc.

In a traditional world, market tests are typically not done by either developers or QA personnel.  That testing occurs only once the product has been released to the marketplace.  The testing occurs by the customers of the product.  Unhappily, the results of that testing show up as missed market expectations, and occur after any hope of fixing the software would be possible, as the product is now in the marketplace.

If we are looking for better quality, both in terms of assuring that the software is written correctly, as well as being the right code to solve the problems that customers need a solution for, you’re going to have to do two things.  You’re going to have to push testing forward, so the feedback loops occur quicker. You’re going to have to automate as much of the testing as possible, so that you can iteratively attack the problem, and not have huge amounts of labor to fix a product that is not on course with customer expectations.  I can’t count the number of times I’ve seen product teams cut out the software testing done after the code was developed so that it could be delivered on a date previously promised. They did it because the labor and time needed to exhaustively regression test the code weren’t on the timelines that were committed to.  Delivering buggy code to your marketplace is an excellent way to help your competitors capture your market. So is delivering on the wrong solution.  This means that shortening the cycle time for this diagram is critical to make this happen!

This diagram is way too simplistic

Absolutely!  In Lean terms, it is a single stream flow of one piece of required functionality within a product that a businessperson knows must be presented to the marketplace as a “minimum viable product”, a “minimum marketable feature”, or even something smaller.  Depending on the process that you use for software development, you may be tempted to have as many of these functionality implementations going on at once.  But that increase in WIP (work in process) causes its own set of problems.  If one piece of functionality is being developed that depends on another piece of functionality code, then dependencies start to rear their ugly head.  Having one piece of functionality take longer to develop than originally estimated can have compounding and confounding ill effects on the code depending on it.  The same is true of a solution that doesn’t “meet the mark” on the non-functional and integrated regression testing aspects.  Note that by waiting until “we are ready to release” before we start this type of testing, we potentially grow an enormous WIP of unreleased code.  Any failure at this stage has a lot more code to fix than if we were able to stay with an ideal single stream flow.

“Rules of thumb” are meaningless

You can find many rules of thumb for the ratio of QA to developers if you do a Google search with the words in the title of this blog entry.  You will find people talk about 10 developers to 1 QA tester, 3 to 1, 1 to 1, and many others.  My feeling is that none of these can possibly be correct.  They can’t be right, because they don’t take into account the abilities of both the developer and the tester.  Highly capable developers may be 10 or more times quicker at producing the same code as less capable team members.  The same will hold true for QA testers.  I had a conversation with Fred George a little over a year ago on this topic, and he recounted an assignment where he observed a ratio of 6 testers needed to absorb the work of one highly productive developer.

Rather than going that rule of thumb route, I would urge you to consider getting closer to a single stream flow on individual things that the software needs to do and employ the “Three Amigos” model that George Dinwiddie explains in Better Software, November/December 2011.  Here, we get the BAs, QAs, and developers at the start to write automated tests that serve as the functional requirements for the work to be done.  If we keep the rate of production of these collaboratively-developed tests in line with the actual rate of production that satisfies the tests, we never have to fear that we have something off balance.  If we find, perhaps with a Kanban analysis, that we can’t produce enough tests to keep our developers happy with enough work to do, we may find that we don’t have enough BA types or enough QA types available for us, and can adjust accordingly.

And, yes, there will always be a place for QA exploratory testing on integrated code.  But that should be automated as well into regression suites that are automated and repeatable.

Flow is the most important thing to a business

You may be asking yourself at this point, “Yes.  I get it.  I need to reduce WIP, and not worry so much about rules of thumb to get software done.  But what about that test in the market?  How do we get better at that?”  The answer there is easy – release more often!  And that will take your continuous integration solution to a whole new vista – continuous delivery, and engender a whole new set of problems that are wonderful to have, such as “how quickly can may market absorb new features, and how can I get them to accept things in a more laminar flow fashion?”

Businesses that produce software do it for a purpose.  Usually a pecuniary purpose.  Understanding the reasons behind why excessive WIP is such a dangerous thing to have may put the onus on the business to see how to incorporate smaller product tests, in terms of releases to the marketplace, more frequently.

So, the right answer is?

Since there is no right answer to the question of “what’s the right ratio”, let’s invoke Kobayashi Maru sort of solution.  For those of you who never saw or have forgotten Star Trek II: The Wrath of Khan, the Kobayashi Maru was a simulation exercise that Starfleet put all of its officers through to test if they could save the civilians trapped in a disabled ship in the Klingon Neutral Zone.  Because of the constraints involved, no cadet at Starfleet academy had ever passed the test.  Even the legendary James T. Kirk failed the test twice, only passing it the third time by reprogramming the simulator.

We can’t win this battle for correct ratios between QA and developers by simple rules of thumb.  But we can fall back on the values and principals of Agility, just like Kirk did for Star Trek values and principles.  We need to focus on the team’s people and interactions (specifically, QAs, BAs, and developers) for as much work as possible up front to increase quality (the most efficient and effective method of conveying information to and within a development team is face-to-face conversation).  Keep WIP sizes small (working software is our primary measure of progress).  Test our code not just during development (continuous attention to technical excellence and good design enhances agility), but get it into the hands of customers quickly and often (customer collaboration).

Let’s change the conversation from one asking for rule of thumb ratios into one that asks for collaborative development, better quality, and faster market realization of smaller and smaller chunks of valuable software.  We can measure and find where WIP is causing resource constraints, and do the traditional 5 step Theory of Constraints solution to fix things.  In other words, let’s turn around the faulty question for an answer (that is bound to fail in practice) into a new quest to deliver, measure, and deliver more of what works.

Photo Source

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Planning Horizons: Decision-making within Agile Frameworks

Organizations need to plan, it’s not a “nice-to-have option”, and they need to do it effectively at multiple levels. In the end, this planning needs to feed an enterprise’s ability to do financial forecasting of costs, cash flows, budgets, etc. A company that cannot plan will most likely not understand what it’s doing with its assets, and inviting a lot of waste in its processes. Yeah, planning IS essential.

As we help our clients through their transformations, we must keep their planning horizons in mind and always in our sights.

Planning Horizons

A planning horizon is the time period over which effective decisions can be made to support organizational activities, for instance delivery of features, customer support, market-reporting requirements/filings, R&D investment, even budgeting and financial planning. Each horizon operates on a different time scale, which is why we talk about multiple horizons, but in my experience companies tend to operate in 3:

  1. Tactical horizon – what I need to know to enable decisions in a timeframe measured in weeks, immediate future
  2. Product/Project horizon – what I need to know to enable decisions in a timeframe measured in quarters
  3. Strategic horizon – what I need to know to enable decisions in a timeframe measured in years, green field of ideas

Clearly the level of detail needed to enable effective decisions for each horizon is different. I am purposefully not defining the exact number for each one. That really does depend on the company in question.

If we are talking about agile organizations working in some kind of time-boxed framework (like Scrum for instance), then the horizons can be defined in terms of those time boxes using concepts of iterations, releases and years, respectively.

When implementing agile frameworks sometimes we lose track of the need for organizations to plan ahead in the cloak of allowing that information to emerge over time. We understand that eventually it will, but often some information is really needed much earlier. We talk about trust, and a leap of faith that it will come, but we don’t meet our client’s need where they are right now: in a state of flux between change states.

I want advocate not losing sight of what is important to the client (organization, division, department) right now, to help them through the change they have undertaken. This is a basic coaching tenet we hold: meet the client where they are now, so we can help them move to where they need/want to go.

3I/3R/3Y Model

To that point, I usually think in terms of a simple 3I/3R/3Y model, where a tactical horizon extends from now to about 3 iterations (3I) and deals with what I’m trying to get done in the now. A yearly product horizon in most organizations lines up with a quarterly release schedule, so that is about 3 releases (3R) in the future. Finally, the strategic horizon deals with what is the next new thing we have to consider to remain competitive for the next few years. Some companies try to plan 5 years in advance, but given the current rate of technological change, I think 3 years (3Y) turns out to be more realistic (and that can be argued should be shorter still! – not going there).

How many times have we heard in companies that “we don’t know what we are going to work on the next sprint until sprint planning”?

This simple 3I/3R/3Y model gives us nice horizons for the tactical, product and strategic planning that needs to take place. All healthy organizations are able to forecast with confidence along those timeframes.

Your Effective Planning Horizons

So next time you look, ask yourself, what are my effective planning horizons? And, how do they support the enterprise? How long can it wait for the emergence of the information really?

I am curious to find out from folks out there if they observe these same trends, and how they have shaped their companies.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Ideal Days: Unnecessary Agile Evil?

Agile teams have a valid need for sizing or estimating user stories. Most teams use a dimensionless scale such as story points for estimating. In some quarters “Ideal Days” are often held out as reasonable replacement for story points. When we look at the reasons for sizing stories and the ways in which ideal days open (or leave open) doors to traditional management styles that don’t support Agile development, we see that there is no real advantage to using ideal days and they tend to retard some of the paradigm shifts that need to happen for successful Agile adoption.

Why do Agile Teams Estimate?
Agile teams, with the Product Owner, estimate or size user stories for two reasons.
• Product Owners need to know how big a story is so that she can compare its relative worth to other stories. That is, in order to properly groom and prioritize the backlog the Product Owner needs to know both the value and the cost of completing the story.
• Teams use story estimates, in conjunction with an understanding of their historic velocity, to gauge how much work they can reasonably commit to when planning a sprint.
In both the cases we don’t need anything beyond relative consistency of estimates. Relative consistency means that, for example, any stories with a size of 5 are all about the same amount of work for the team to complete. Similarly, we would expect a story of size 10 would be about twice as much work as a size 5 story. A dimensionless relative size is all that is needed.

Agile “Estimates” are Intentionally Imprecise
It is a good practice to use predefined sequence of numbers such as a Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc) or a geometric sequence (e.g., 1, 2, 4, 8, 16, 32, 64) for story sizes. This practice is good for two reasons.

First, it tends to reinforce “just enough” when it comes to estimates. Any estimate is, by definition, likely incorrect. Teams can waste a lot of time chasing an illusion of precision and accuracy when in practice, unknowns will almost always cause estimates to be inaccurate. They need to be good enough for the purposes discussed; any work to go beyond that is waste.

Second, sequences like Fibonacci Numbers or a geometric sequence, provide values that get further apart as they get larger. This helps build uncertainty and risk into estimates of larger pieces of work.

Story Points or Ideal Days?
Story Points are a true dimensionless measure. Any given team’s notion of what constitutes a “point” is independent of any other team’s estimates. My five point story may be twice as much work to complete as your five-point story. As long as my sizing is relatively consistent within my team and our stories it doesn’t matter if they are consistent with yours.

Ideal Day estimates are not really dimensionless. They are effort estimates, not abstract, dimensionless sizes. The standard for an Ideal Day varies, but for the sake of our discussion we will assume this definition: one Ideal Day represents the amount of work an average developer could complete in one eight hour day completely free of interruptions such as drop-ins, phone calls, meetings, etc. So, what is wrong with using Ideal Days? Ideal Days open the door, intentionally or not, to managers and PMS who seemingly can’t keep themselves from “doing the math” with Ideal Days.

Well, let’s see here. You are telling me that the team will produce 42 Ideal Days in the two week sprint. But I see that you have a 7 person team, so if we assume an 80% loading factor, the team’s output should be 56 Ideal Days (80% x 7 developers x 10 days). Shouldn’t the team be able to include a few more stories in the sprint?

Needless to say, such conversation seriously undercuts the team’s decision making and self-management!
Ideal Days also encourage comparisons between teams, since the basis for estimating is presumed to be standard.

Mary, I see that your team is averaging a velocity of around 7 Ideal Days per team member for the last few sprints. Bills team is averaging 8. That’s about 15% better! How come your team isn’t as productive as Bills? Can we boost their productivity a bit?

Given the intentional imprecision in Agile estimates, even with Ideal Day estimates much of the difference between Bill’s and Mary’s teams may be accounted for by that imprecision.

When managers and PMs start “doing the math” with Ideal Days we easily fall into a game where developers estimate not based their view of the work, but based on what they think the estimates should be to keep voices outside the team happy. That kind of lack of transparency is anything but Agile!

Ideal Days blog

Managers and PMs are not, as a class, evil or stupid. The shift to a team-based, high trust paradigm is hard. Ideal Days allows them to more easily stay in the old paradigm and to keep using the tools they know how to use. Story points encourage us to shift our thinking to a more Agile mindset. Managers and PMs have a legitimate function. When they push back on dimensionless “estimates” in Agile our response should be to point out the risks inherent in things like Ideal Days and help them develop the skills and techniques to manage in an Agile environment.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Estimation is a Cruel Mistress

Estimation is a thing of beauty.  It’s the crystal ball that every business wants to allow perfect decisions to be made.  It’s sort of a yearning, a siren song that calls to us and tells us everything will be wonderful.  If only we could estimate well, then we could have perfect insight beforehand into what things will cost (in terms of research and development, marketing, etc.) and what those things will produce in benefit (in terms of both extrinsic as well as intrinsic values).  Our decisions would be risk free, and therefore we could make perfect decisions.

But estimation is also a shiny object that can become very distracting.  Unhappily, what far too many people fail to realize is that, no matter how careful we try, estimates are not exactimates, and decisions have to be made with less than perfect accuracy.

Estimation is Bad – It is Nothing More Than Waste

Why do we feel compelled to estimate our work before we start work?  There are many reasons, but the first one that we should dispel is that we need to estimate before we work.  Estimating before work starts is something that we’ve been told since the days when project managers were first conceived of.  Estimate, analyze, design, code, and test.  We were also told that we needed to get “signoff” before we moved from one stage to the next.  And estimation was always fundamental in those moves.  If the estimates were high, and the benefits were low, then our manager would tell us to not work on the project now.

But what if we challenged that assumption?  What if we could produce solid working software, ready to use to make our company money, and do it efficiently without any sort of documentation whatsoever?  Why wouldn’t we do that?  In fact, if those assumptions are actually false (that is, you could produce positive value without estimating), then you’d be certifiably insane to create all of that documentation which isn’t needed!  Why would you create unnecessary documentation when you could be creating code instead?  After all, we get paid for the software and the value it produces.  No one buys our documentation about the process to get to software!

Estimation is Good – It is Needed to Plan

Well, there actually is a use for estimation.  Even in that perfect world where software is getting created with only conversations between the business and the technical sides of the project, there’s still one thing missing.  And that’s planning.

A business needs to plan and mold its customer expectations based on the capacity of the organization to produce useful and valuable software on a timetable that makes sense to both the business in terms of revenues, and the customers in terms of value received.  Unless we can have some form of plan, we can’t set those expectations.  And getting expectations from customers, and therefore expectations of things like revenue from customers is important.  It’s how we plan our business.  We need to marry and couple those plans together to have a viable business, pay salaries, and so on and so forth.

The job of the business will be to set broad expectations for what might be available in what approximate timeframe, and then manage those expectations as the dates begin to get close.  So, when the organization plans its roadmap, the huge epics on the backlog will need some sort of rough estimates to couple to the velocity of the teams creating the software.  That coupling of plans allows the business to derive the expectations of when things might be available.  It’s simply not acceptable for customers to ask, “So, what features are on the horizon for the software?” and get a response of “Oh, gee.  We don’t know yet.  But we’ll let you know what we did when things are done!”

The Evolving Role of Estimation in an Agile/Scrum Setting

Estimation in Agile and Scrum is not a one-time learned skill.  Because of the true difficulty of actually creating accurate estimates, it is rarely done well.  The real point of this piece is say that accurate estimates are really never needed for development, but only estimates good enough to set reasonable expectations are needed for planning.  But there is another reality that estimation clarifies.  As the Delivery Team moves from more traditional development into an Agile model, their ability to estimate appropriately increases.  There are at least two causes of this: the Delivery Team remains constant over time, so people learn their collective capacity, and the Delivery Team begins to understand that estimation, by itself, is not needed to actually produce software!

So, what progression can one expect a Delivery Team to go through when making the transformation from traditional to Agile development?

At first, when the team works on very large epic type stories, many times the team is so poor at estimating that they routinely miss iteration commitments.  When we examine how the software is being created, we see that the team is actually practicing a form of “Scrumfall”, where a story starts in one iteration or two with analysis and design, followed by another iteration with implementation, followed by testing, etc.  Tasking is used to try to figure out what is possible, and the iteration planning sessions are laborious, lengthy, and end with poor results.

As the Agile transformation proceeds, it is common for the team to still be using fairly large epic type stories. Many times, these stories are “assigned” one story per developer per iteration. Since the stories have large story point sizes, tasks are still used to assure that story will fit into iteration.  The results may be marginally better and the iteration goals may be somewhat more predicable.  But the iteration planning sessions are still intolerable.  Yet somehow, the fragrant scent of change wafts in the air.

Then, as the transformation progresses, smaller user stories, perhaps around 5 for each developer per iteration, start becoming common.  The stories will now still vary in size, but we no longer see things like a story that eats an entire iteration.  The Delivery Team becomes much better with sizing these stories using relative estimation.  Tasks are still used to ensure that adequate capacity will likely be available from the entire team.  But the tasks are now more of a cross-check rather than the way that the iteration is planned.

As the transformation progresses further, even smaller user stories get written and used for iteration planning.  Those smaller stories have better foreseeability, so less uncertainty is present, which makes the estimates better.  Additionally, because of its experience working together, the team starts feeling comfortable with relying entirely on velocity to get to an iteration commitment.  It’s at this point that tasking becomes a waste.  Iteration commitment can be done purely by looking at team availability and story point commitment!

Further down the road, the transformation starts having even smaller detailed user stories that all are fairly similar in size. The act of negotiating while writing the right story (with appropriate acceptance criteria) now allows the team to not even estimate anymore. We begin to start writing stories that are more or less uniform in size.  Iteration commitment can be done purely by looking to the team availability for the iteration and just counting stories.  Oh, and by the way, once we can avoid doing estimation during iteration planning, we get back a significant amount of time for creating even more product value per iteration.  Of course, all of this reduction in estimation is really just continuous improvement doing its job!


Estimation, like beauty, is something that we are drawn to.  We are attracted to the idea of estimation and feel that somehow if we possess a great way to be comfortable and good at it that our lives will be better.  But, at least for most of us, we have to be careful to not fall prey to its deception.  Our lives are immensely better with things like openness and honesty, not just crass momentary illusions of what seems beautiful.  In the product development world, at least, those values help us achieve the goals that really matter.

Thandie Newton as Stella in Guy Richie’s 2008 film “RocknRolla” (http://www.imdb.com/title/tt1032755/). “Beauty is a cruel mistress.”

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



What Big User Stories Could be Telling You

User stories are intended to be a high level description of some functionality. It is, however, common to find user stories growing into specs or large use cases that resemble whatever the organization used to do, back when they did large requirements documents. Comments like “The stories are not detailed enough to start development” or “This took much longer than expected so we should have more acceptance criteria for next time” can become common. There is a balance here that we should watch and adjust carefully. And most of the time we think the solution is more story documentation.

Here is the story card AND all the acceptance criteria, wire frames, specs, use cases, test plans, flow diagrams, architecture...

Why User Stories Get Big

I like user stories as an easy to understand idea for a company to start thinking about a light weight way to communicate needs, features and benefits. It is hard to describe in brief sentences all the forces that pull organizations to keep them thinking in lots of details. A few might be:

  • A culture and history of Big Design Up Front that makes it hard for feature definition to happen just in time.
  • A continued need for long range planning requiring estimates for work that will possibly take months before it actually starts.
  • Skilled technical people who are accustomed to talking about technical details instead of the needs of the user.
  • And more…

Lack of Focus

The most powerful and subtle force to cause “user stories” to grow is a continued lack of focus for the people defining features and those creating the features.

For example, if I am Product Owner of 5-12 products working with 3 teams who are all working on multiple products, I am not able to think of a feature, collaborate on it’s definition as it is built, see it created and then think about the next feature. I have to document my thinking of every feature because one hour from now I have to think about other features that also might not be built right away.

The key to being truly Agile is to finish stuff. The more inventory of ideas, features, undeployed code, etc. that we have, the less Agile we can be.

Have Conversations

In short, Ron Jeffries, the inventor of User Stories, said that the user story should have “3Cs” of attributes: Card (small enough to fit on an index card), Conversation (is a place holder for conversation) and Confirmation (a definition of when we are done, such as acceptance criteria). Most of the symptoms prevalent when stories grow big are likely indicators that the Conversations are not taking place and people are writing stuff down in an attempt to fill the gap.

Don’t write more stuff down. Figure out why the right conversations are not happening. i.e. “Individuals and interactions over processes and tools.” That said, sometimes what we see as an over-documented abuse of the user story is a vast improvement on what the organization used to do. We have to temper our zeal with a dose of client reality as we work to get incrementally better.

Do you see user stories getting too big? If you don’t use user stories, does what you use help or hinder conversations? What is your balance between the ability to deliver vs. the need to document thinking?

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Practical Systems Thinking: Don’t Let Inertia Become the Constraint

Congratulations! You’ve gotten to the fifth step in the Five Focusing Steps of the “Theory of Constraints”. That means you’ve broken the constraint in your system!

But, your work is not done. As a matter of fact, it’s just starting. You see, once you break a constraint in your system, a new constraint will always emerge. Yes, you elevated the throughput of your system, but, as you’ll see in this segment, you must be relentless about breaking the constraints that continue to emerge.

In Eliyahu Goldratt’s CD Series, “Beyond the Goal”, he discusses the dangers of inertia and what he means when he says ‘don’t let inertia become your constraint’. He’s referring to Internal Inertia, something we must combat against within our own team(s). In other words, don’t become content or complacent.

But, beware! There’s another form of inertia, one that is much more difficult to identify and overcome: External Inertia. It’s the “inertia” caused by the set “rules” within your organization, the “that’s the way we’ve always done it” mentality that may resist the changes you implemented when you broke your constraint. The challenge with these rules is that they were good, and even helpful, at one time, so people are reluctant to give them up. Teams realize that these directives were put in place to help the organization be more effective based upon the way it was operating. But now, they may not realize these precedents are no longer relevant since we’ve changed the game and the way we think about the system.

Check out this video as I expand on the concept. And if you missed any of the previous installments of “Practical Systems Thinking”, check out the “You May Also Enjoy” section below this clip.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.