The situation

Recently, a team I was working with had to react quickly to an unexpected software release deadline. The project environment is extremely complex (i.e. federal regulators, internal auditors, two outside vendors, three applications, multiple data sources, distributed team, compliance PMO, short- and long-term solutions in parallel, and more), so the fact that there was a missed communication is not surprising. Unfortunately, the missing information was that federal regulators were expecting the first release of the new software in 12 business days! The good news is that the team found out before the deadline date. The bad news is that the team found out only seven business days before the release signoff deadline. Also, the deadline date was during the monthly release moratorium period. So there’s that.

The decision

All was not completely hopeless, however. The regulators did not put a restriction on how much to release, just that there must be a release to show significant progress toward compliance. Prior to that, the team had been targeting a release in 6 weeks, based on the business value being delivered weighed against the cost of a software release. In particular, the first release carries significant one-time costs related to setting up environments, service IDs, users, etc. Obviously, most of those costs lost some importance balanced against non-compliance, so the team began preparations.

The first decision needed was what to do about the current iteration. The release requirement came on the third day of the iteration, so there were stories in-flight – some that were almost ready for demo. The Product Owner’s first reaction – and the correct one – was to declare an abnormal termination of the iteration.

“An abnormal termination is essentially blowing up the sprint and starting a new sprint instead. An abnormal termination is most frequently the result of a dramatic shift in business priorities – something previously considered important is no longer important, or something even more important is discovered.” – Mike Cohn, Making the Decision to Abnormally Terminate a Sprint

The Scrum Master gathered the team and the announcements were made: the iteration is over and immediate iteration planning must commence. The next important question was, “What will be in the release?” If this were a waterfall project, that would be difficult to answer. After just six weeks on a typical waterfall project, we could expect to have a draft of the requirements document. On an agile project, however, the goal is to deliver working software early and frequently in order to accelerate the feedback loop. Even though there were many tasks to be done before the software could be deployed to production, the code itself was potentially shippable at the end of each iteration. The only way this could be possible was by working with the Product Owner to create independent stories that deliver business value. In other words, the team could welcome the date change because they had good story slicing practices.

Splitting stories into small, vertical slices

Whether you are part of a waterfall or agile project, some high-level concepts remain the same:

Goal is to deliver a quality product in a predictable, efficient and responsive manner;
Activities – in some order and frequency – are to define, gather, analyze, design, code, test, release, maintain, and retire;
Testing in a production-like environment prior to going live; and
Decomposing the work into manageable components.

One of the biggest challenges for teams that are new to an agile approach is adopting a “vertical slice” approach. Teams aren’t used to thinking about decomposition this way, and there will be comments like “Our system is too complex”, or “We need to build really big features because end user training takes so long”. However, there is almost nothing that can’t be sliced into a story that delivers incremental business value.

In the second part of this article, I'll talk more about what I mean by vertical slicing and give some examples.