Consider what it takes to completely finish a story in our organization.

  • Demo requirements were met
  • UI design finalized (layout, styles, fonts, controls, colors, etc...)
  • User text finalized and mistake-proofed
  • All text translated to Spanish, Germal, Italian and French.
  • User manual updated
  • All bugs deemed by PO as need fixing for release were fixed
  • Documents for FDA updated (SRS,STD,STP,STM,UFMEA, DFMEA, SDD, installation)
  • Requirements were written and approved by PO
  • UI spec was written and approved by PO
  • All tests (final acceptance and integration) written/updated and executed - synced and agreed with test manager
  • All FAT tests were approved by QPE
  • Regression testing was done
  • Code was reviewed and documented
  • Unit tests were written and executed - synced and agreed with software manager.
  • Refactoring, if needed, was done - synced and agreed with software architect.
  • Design was documented
  • Installer was updated (If needed)

With so much work needed to fully complete a story, the team stops being nimble and it becomes more difficult to try out new features quickly.

As far as I see there are 3 ways to solve this problem:

  1. Do more "Spike" stories which don't meet the "Done" definition but serve as quick prototypes to gather feedback from users.

  2. Get feedback from users all the time during the Sprint rather than at the end of it. So half-way through the story you could already gauge what users think of the story and quickly adapt before doing all the heavy stuff (translations, user manual and such).

  3. Relaxing the "Done" definition to require just basic testing and bug fixing. This way the team won't have a potentially shippable product at the end of the Sprint, but it will be very quick to try new features and technical innovations without suffering from the burden of documenting everything, writing user manual, doing design polishes, etc...

Which option would you pick and why?

Thank you.

  • 1
    I think your bullet point list would better suite definition of a "feature" rather than a "story". For a feature, you clearly need all those things, but why can't you string multiple smaller stories together to deliver this? For example you could release functional product without having translations into every other language and get a real-use feedback on how the stuff you made so far actually works.
    – DXM
    Commented Mar 1, 2014 at 18:26
  • You could, but it wouldn't be exactly Scrum. In Scrum you are supposed to deliver a potentially shippable product at the end of each Sprint.
    – Eugene
    Commented Mar 1, 2014 at 18:59
  • 2
    If what you said was true, features would be indivisible units of work and there are many features which require way more than one iteration of effort to be completed. So only way to break those features down is to deliver them partially. "Potentially shippable" means that at the end of each story, your product builds, installs and is usable. If a feature is 25% complete, the users (both end-user and QA) need to be aware of work in progress and that's okay because demos at the end of each sprint always demonstrate work in progress. The key is that at the end of each sprint a)you shouldn't...
    – DXM
    Commented Mar 1, 2014 at 19:36
  • ... break existing functionality and b) deliver new functionality such that it can be evaluated based on what's there now. This will give you better feedback and help you adjust direction to complete the work on the feature in progress.
    – DXM
    Commented Mar 1, 2014 at 19:37

3 Answers 3


First of all, I would try to move some of the items from your "definition of done" to the "definition of ready". The definition of ready determines when a story is in a sufficient state to be implemented by the developers.

The items I would try to move to the "definition of ready" are:

  • Requirements were written and approved by PO
  • UI spec was written and approved by PO

these items typically involve a sequence of back-and-forth discussions between the PO, stakeholders and the team and give the story shape. For that reason, they should be done before the team can pick up the story for implementation.

After that, option 2 seems the best to me. One of the basic ideas behind agile (and scrum) is that you should be in close collaboration with (representatives of) the client and users, so you can easily align the idea of the team what they need to make with the actual needs/wants of the client. The demonstration at then end of a sprint in scrum is a regularly recurring milestone at which the team can show the world what they have accomplished, but there is no reason why you can't ask feedback during a sprint.

If there are regular discussions what form the new features should take, then you could consider introducing a special "proof of concept" type of story that has a relaxed definition of done and that can be utilized by the PO to get a feel for how a feature would work out. Such stories should be implemented on a separate branch to ensure they will not be included in an eventual release. To emphasize, it is a decision of the Product Owner if a particular story is a regular story or a "proof of concept" story.


I can't judge, but it seems to me that your definition of done is fairly unrealistic. Of course, it's up to your organization, but I would first consider if you need, for example, localization, before delivery, after all, only one language is used at a time. Maybe it's really necessary though!

So - after I have made sure there's no value without all those conditions, and assuming the list is still valid - I'd take one of these two ideas:

  1. Reduce the scope of each story so it fits in an iteration and make the team do multiple stories by parallelizing. In other words, maximum elapsed time must be one iteration, however more than one story can be played concurrently.

  2. Remove a set of constraints which only apply to the actual deployment (e.g. user manuals?) so the team can be quicker, then add a "release" sprint every so often, when you actually release. Not very agile, but possibly something you need to do.

More in general: adopting an agile process is highlighting a risk factor in the way your organization works. This is quite a common occurrence and, in my opinion, is a desirable trait of agile methodologies. In particular, there seem to be a very large amount of ceremony. I would start by investigating why that can't be reduced massively first, more than trying to fit the methodology to your situation. Have you considered asking the team to help you (e.g. in a retrospective?)


I note that your question uses the tag "Scrum" and yet, your list of tasks to finish a story leads me to believe that you cannot be doing Scrum. Here's why:

  1. Scrum doesn't require demo's. The closest we get is the Sprint Review, which is still very different from a demo
  2. Scrum doesn't mandate requirements or specifications. The closest we get is Product Backlog items and the overhead in creating them is considerably smaller than for creating requirements and specifications
  3. Scrum doesn't have a role of 'test manager'. If you're using an external one, you may be breaking a fundamental element of Scrum (that the team be fully cross-functional)
  4. Ditto for the role of 'software manager'
  5. Ditto 'software architect'

It seems to me that you have a variant that may be based on Scrum but is not Scrum. I suggest that your work flow has some process heavy elements applied to it that are dragging you down and hence your very understandable discomfort.

My advice would be to go back to the roots of Scrum, identify your dysfunctions, and then work hard to resolve them.

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.