Synchronous Work Within a Sprint

Posted on April 15, 2011


If you choose to implement Scrum, the most widely adopted Agile Methodology, then you will need to do synchronous work within short time-boxes, called Sprints.  A Sprint, according to Wikipedia, is “a time period (typically 2–4 weeks) in which development occurs on a set of backlog items that the Team has committed to.  Also commonly referred to as a Time-box.”  This definition is somewhat vague.  My equally vague definition of a Sprint is, “a set span of time (between 1 day and 4 weeks), in which, Done-Done is achieved.”  So, what is Done-Done?  Well, that is up to the team to determine and agree to based on their domain.  This is why the Sprint definitions are purposefully vague.

For me, at the most basic level, Done-Done means that the feature (or story) is coded and tested.  This means that while your developers are coding, the testers will be writing test cases and hopefully, testing the features as they become available to test.  Also, it is likely that your developers will need to work together on the same feature, so that they can complete it faster.  This is quite a bit different from more traditional approaches to software development, where individuals are responsible for an entire feature or an entire layer spanning multiple features.

So, why would we change the way we develop software?  Simply put, employing Sprints correctly reduces cycle time in our feedback loops and minimizes and/or removes the 7 wastes of software development (OK, maybe not so simple).  This allows us to:

  • Get from idea to usable product faster
  • Better predict project timelines
  • Increase internal and external quality of the product
  • Increase value delivered by always working on the items with the highest business value
  • Fail fast
  • Inspect and adapt at the team and development process level at regular intervals to drive continuous improvement
  • Receive user input and course corrections at regular intervals
  • Minimize over-production of code, tests, documentation, functionality, etc.
  • Know where we are at any given point in time, based on fully functioning, business value-add features
  • Reduce work-in-progress by achieving Done Done every Sprint

These are big promises.  So, how can we possibly achieve all of these things?  Well, there are many things that need to be done to ensure that we meet the expectations set above.  Each of the practices or processes listed below are essential to successfully implementing Sprints.

  • Collectively define Done Done
  • Keep the backlog well groomed (INVEST)
  • Keep a focus on quality
  • Automate (builds, tests, reporting, etc.)
  • Collaborate continuously & communicate openly and freely
  • Control work-in-progress (Focus)
  • Create clear role definition
  • Maintain transparency and visibility
  • Swarm issues (mob mentality)
  • Keep the Product Owner highly engaged
  • Protect the team

There is most certainly more that can be done to ensure the success of a team, but these are the base.  Teams should work to master the base before they begin adding new practices or processes.

More to come on the benefits and the base practices and processes of Sprints.