Short Sprints vs. Long Goals

  • strict warning: Non-static method view::load() should not be called statically in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/views.module on line 906.
  • strict warning: Declaration of views_handler_argument::init() should be compatible with views_handler::init(&$view, $options) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/ on line 744.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/ on line 607.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/ on line 607.
  • strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in /hermes/walnaweb12a/b57/moo.greydragoncom/nodsw/sites/all/modules/views/handlers/ on line 159.
Leeland's picture

Running a development using SCRUM mixed with Agile has a lot of benefits. But, every once in a while (read as "yesterday") a requirement comes up that just seems to defy all logic and being able to be split down. This isn't the first time to run head on into this large wall (or immovable object). Although rare, this does happen.

Many Agile purists claim that such cases are not really as solid as people claim. These people often remind me of those folks who never had a child pontificating about how easy it is to keep children in line and happy. The argument generally is that the monolithic requirement (story/use case) is miss-understood or improperly defined.

Suggested solutions to resolve the "erroneously specified requirement" usually look like:

  1. Do a time boxed spike on the story with the focus of breaking it down.
  2. Create a technical spike story for making a vertical slice through the larger story creating either a framework for more functionality or at least provides some of the base non-functional requirements.

When planning the next sprint and everyone goes silent with blank stares when a backlog story comes up, it is obvious that the story is moving into uncharted territory. As the team does not have anyone with experiences that provide some guidance for solution paths the above steps really do work great. Time boxed research spikes give team members time to engage experts (via articles, forums, direct interviews, etc.) on the story requirements which creates ideas on how to tackle the technical implementation. Vertical slice technical spikes do the same thing with the added benefit of creating some functionality. Also the vertical slice allows other teams to begin engaging the ideas which creates feedback to the team.

However, there are still times when a backlog item comes up that just defies all attempts to break it down, take a vertical slice, or in any way cooperate with the Agile Scrum belief that large stories can always be broken down. This rare monolithic backlog item usually involves complex systems that have to have a new behavior, or an emergent behavior modified.

The two first hand experiences in my past involved:

  1. A new feature to be grafted on to a legacy financial system of epic proportions (that was developed using semi-"water fall" with a staged incremental development method.
  2. The restoration of a "feature" many customers were using in many previous releases which was an undocumented emergent behavior. The behavior vanished with the rollout of a new release where there was a lot of refactoring, new features, and cleaned out cruft. (Most of the development teams claimed the behavior wasn't possible in the first place.)

    So the question then becomes "How can this be done in the time allotted?" For me, Agile is really about consistently doing "good" things given each circumstance you face. Naturally, the teams tried the spikes (both) on two different sprint cycles. Neither spike succeeded and the team was seriously stuck, while the customers were very upset. The solution in both cases, was painful and did not make the team happy at first, however, happy customers and praise after the fact made up for the initial pain of the solution.

    What we did took 3 sprints in the first case to finish and 2 sprints in the second (because we already had some ideas from the first time). Essentially the team took on the backlog item by itself and worked on nothing else until they had solved the problem. Yes this does mean that their velocity went to zero for 2 sprints the first time and 1 sprint the second time. In the end the teams velocity average self-corrected once enough additional sprints were done to reduce the effect of such aberrations.

    If a team is consistently knocking out two 8 point items and a 13 point item their sprint record might look like:


    Stories Done

    Sprint Total Points

    Velocity Average


    8 + 8 + 13




    13 + 13




    5 + 3 + 3 + 8 + 8




    5 + 5 + 5 + 5
















    13 + 13



    While the initial hit of making zero points hurts in the end it resolves itself. The Team average will self-correct and over time the zeros will no longer affect the score.

    When a story defies attempts to break it down into smaller use cases the solution is to not waste time arguing about how it isn’t possible. If you have the time, try the spikes. If not, take on the task, realizing that there are some zero scores in store.

    How did we solve these problems?

    In the first case the team refactored large portions of the legacy system adding integration and unit tests as we moved functionality around only as needed to add the new functionality. The result was a number of performance enhancements (by shear accident really), some much needed refactoring of core functionality, the new feature needed, and a very happy customer.

    For the second case we tossed out the sprint planning/tracking for that team (still used Scrum style, just didn’t try to shoe horn in the out of band work). The team managed to find a customer that was not critically using any of the new features of the latest release, convinced them to roll back to the previous release, then spent a whole sprint at the customer’s site with the customers developers “defining” (documenting) the emergent functionality and learning how it was being used. Then the team spent the next sprint in an epic battle to design, implement, test, and publish the “restored” functionality to the product line. The results were an early new release being made available to any customer that wanted the functionality back and the company taking the team out to a “thank you” fun event for the over the top effort. The team actually finished and delivered the work a week prior to the “normal end of sprint” time line and the company let them just decompress for that last week. Then they kicked off the next sprint normally.

Thread Slivers eBook at Amazon