Scrum: relaxing "done" or using spikes?

Question

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.

Answer 1

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.

Answer 2

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?)

Answer 3

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.