What is the difference between:

A) The details evoked & scope definitions & acceptance criteria gained from the ongoing "user story conversation" a team should have with the PO, BAs, and stakeholders during a sprint


B) Unplanned Scope Creep (which causes a story estimation to be missed, a story to not finish the sprint, etc).

More specifically, how do you evidence scope creep & estimate/schedule slip caused by A vs. B?

Full Story

I have an agile team of cross-functional front- and back-end engineers, designers, QA testers. We work in a Kanban continuous pull-based flow, decoupled from a number of Scrum ceremonies like stand-ups, backlog grooming, retros, etc.

We receive project/feature documentation from the executive team defining high level business value and high level low-detail specifications of a desired project/feature.

I act as the PO (among other hats I am wearing), which means I am involved in this executive level scoping, learning the feature vision, business need, and finer business logic during this process.

Next, the team kicks off feature development and breaks this initial documentation into user stories, each story defining a MVP-type story which can deliver value on its own. The team grooms the story and comes to a common agreement. At this point, the team & PO aim to have 99.99% defined business logic, but leave the "how" open.

When development starts, the team is encouraged to continue the user story conversation to evoke finer and finer detail regarding UI, UX, and minor business logic behavior. This requires conversations with myself, our creative director for art/design direction, and our CEO for strategic product direction. Along with this conversation, development and UI exploration is underway, which generates knowledge, which in turn generates new understanding and possibly new or modified business requirements.

The problem I run into is a near infinite "internal iteration" on this user story conversation. The creative director goes into perfecting the UI/UX, the CEO goes into perfecting the business behavior of the feature, and I struggle finding a balance between delivering a MVP and delivering a feature that all stakeholders are happy with.

My current solution is to ride this fine line by breaking major departure from the initial user story into a separate user story, while allowing minor tweaks of all kinds to proceed as part of the existing user story. This approach feels OK, but I feel it might contradict agile/lean thinking. Then again, I feel that A) MVP with PO/stakeholder sign-off and B) User Story Conversation might be contradictory in their own way and that they can't both be applied at the same time.

3 Answers 3


It looks like you have a problem in the ways stories are written. Stories represent an aim which has a value for an actor.

If you think about the Mike Cohn version of user stories: "[The actor] wants to do [the aim] in order to get [the value]". If you can identify these three elements, the scope follows logically.

The conversation that needs to happen on the user story is about the simplest, or cheapest way to get to that value delivered to the actor by enabling the aim.

For example imagine this story for Stack Exchange sites:

As a registered user I want to change my avatar so that my avatar is the same as other sites.

What is the simplest, cheapest way of achieving this? Here's where the discussion needs to happen. It should start during planning and it could go like this:

Team member A: "We could add a new form with a file upload on the user page"

Team member B: "What about dragging and dropping an image from a file to the avatar itself?"

Team member A: "Yes that's simpler, let's do that"

The decision is then annotated on the card (or whatever you use to track stories). It's an implementation detail.

During development, a couple of problems/opportunities emerge.

  1. It's not easy for a user to know they can drag and drop to customize
  2. A developer realizes that it would be cool to support copy/paste as well as drag and drop.

How do we handle these cases?

Item 1 means that, in order to provide the agreed value to the user, an extra piece of work is necessary, in particular in this case it could be a label explaining the functionality to the user. This is clearly part of the story. It needs to be done in order for the story to be complete and valuable. The decision should be noted on the card.

Item 2 is an insight that was gained as the team acquired more knowledge on the subject. It does provide extra value, but is not necessary to achieve the aim agreed on: the value is over what was agreed. Therefore, in this case a new story is added to the backlog: "As a registered user I want to change my avatar via copy/paste so that I can change it without saving a local file on my system."

As you can see, it should be quite easy to understand what is "scope creep" and not. Keep in mind that there is no such thing as scope creep in agile: scope creep is an essential by-product of the methodology, it is something we actually encourage and it has a correct place, as new stories.

  • I am accepting this as the right answer about other high quality ones because without fully explaining the details of how we write stories you basically hit the nail on the head: by providing implementation detail we create an iteration silo outside of our team which turns the team's work into a silo in itself.
    – Bernardo
    Commented Jun 29, 2014 at 14:43

Your situation feels pretty familiar to me (as well as to many others out in the real world, I suspect).

The Agile approach welcomes change, even last minute change, so it is fine for stakeholders to continuously refine / extend user stories and add more details or even new requirements. As you say, it is not easy to keep individual user stories "under control" though. Once a story is in progress, it should not be changed or extended so much so as to render previous estimates and plans invalid. However, it is fine to change or refine smaller details based on feedback from stakeholders. As you note, there is a fine line of balance to find here. But there is nothing inherently un-agile in it; I believe that all agile teams face this dilemma all the time.

The real contradiction

is, as you too note, between creating signed off project/feature documentation early on, versus ongoing story grooming. I sense there may be an organization level gap between your team's agile process and the more traditional approach of other departments, including the executive team.

I think from their perspective a part of the problem may in fact be that they don't see the individual user stories your team created, only the original full document, which has no clear boundaries between the different features. Thus they don't perceive when they are extending an existing story "too much" so that they are adding a completely new story.

Agile transformation

It may help to explain them in detail how your team is working, what the agile approach is and why, what are its benefits compared to the traditional Big Specification Up Front approach. And also to explain them the current problem from your team's perspective. Ideally, you could convince them to adopt user stories from the very start of the process. That may make it easier to sense the relative size of each story (using feedback from the dev team) and to avoid bloating them too much.

(This may be tricky or - in the worst case - even impossible, depending on a lot of factors including the way of thinking of higher management, your and your team's situation and departmental status, organizational culture, "politics", the state of agile transformation within your organization etc. So assess these and proceed with caution, or not at all if you feel it too risky. Without more details, it is impossible to give more concrete advice on this. Except maybe two:

  1. get allies.
  2. if you haven't yet, get and read Succeeding with Agile by Mike Cohn - you will find a wealth of useful and practical advice in it. )

Make stories smaller

Another important factor is to ensure that only sufficiently small stories get into a sprint. A story at this point should be small enough to be conveniently finished within a single sprint; preferably it should not require more than a few person days' worth of work. If it's too big, it should be sliced up into smaller stories. Working with small enough stories help control "scope creep" as well, as you can only add so much to a small story before you notice that it's starting to grow overly large, so it's time to slice it up.

"Infinitely" refining stories

is fine and fully agile, at least if done the right way. That is, as long as the stakeholders and the team can agree on a set of successive refinements to a story or epic, so that the team can deliver the new features to stakeholders as a series of valuable product increments. Learning to slice up stories into suitably small increments is an art which requires patience and long term practice. And feedback from you and your team towards stakeholders can help a lot here, as well as regularly demonstrating completed, working product increments to them - I don't know how often you do this?

  • Upvoted for great feedback and for addressing fundamental Agile principles & issues, but had to pick a different answer. Thanks!!
    – Bernardo
    Commented Jul 3, 2014 at 17:41

Attempt at answering my own question

My initial feeling is as follows:

  1. Need more executive buy in into Agile: executives are too involved in the details and implementation "how tos"; this creates a more top-down, contract-based approach than an iterative, hypothesis-driven approach.

  2. If team did true iterative development, this wouldn't be an issue: the team would iteratively and incrementally evolve to the right solution. The exec and product/BA team needs to continue defining high level strategy and vision, and let the team do the business and UX exploration necessary to arrive to the optimal solution.

  3. If PO/BAs did true hypothesis- and data-driven product specs, this wouldn't be an issue. Instead, PO/BAs and executive team engage in historical and "gut feel" feature design, based on "what has worked before" and "what I think will work"; this causes

  4. Team needs to learn the business at a much deeper level to be able to make certain decisions in the name of the customer/user without needing as much PO or executive input. If the team was able to decide between two business logic options based on their knowledge of the product, user, and market, they would move towards true self-organization an product ownership.

  5. Clear team accountability: drive the team to know why they are building a feature a certain way and to take responsibility for its success. This requires giving teams the ability to make independent decisions, and then to measure success/failure. More independence comes with more responsibility and accountability.

  6. Product needs a full time dedicated PO who is a subject matter expert and who has a team of BAs and/or data analysts at his disposal to engage in true hypothesis- and iteration-driven development.

Overall, this is a process that is very complex and time-consuming to implement, not to mention risky.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.