Replacing a Working System
Hello everyone,
I am the Scrum Master of a team about to replace a complicated, large working system. The system is being replaced because it requires the business to pay annual fees for external data requests. The new system will use its own data and therefore cut out those fees. (This is the simple version but it’s unnecessary to explain further.) I’ve been working with the Product Owner to help him write the User Stories/understand how this can work with Scrum.
The system itself, from an end-user perspective, is actually quite simple, but the back-end is what makes it extremely difficult.
The first problem identified is:
Until the new system is built in full, the old system cannot be replaced.
This is down to the fact that portions of the old system cannot be removed or turned off. If a component is removed, the entire system must be removed otherwise the business operates at a loss.
The second problem identified is:
Building components of the new system to provide value at the end of a Sprint (splitting a large User Story vertically) would cause a large amount of re-work architecturally to be required to add the other components later.
For example:
As a customer, I want to be able to perform A, B, and C, so that…
As a customer, I want to be able to perform A, so that…
As a customer, I want to be able to perform B, so that…
As a customer, I want to be able to perform C, so that…
It might take one Sprint to finish each story separately, for a total of 3 Sprints. If all three are combined, it might take 2/3rds of the time, for a total of 2 Sprints, however, the first Sprint would provide no tangible value/potentially releasable product, only ‘back-end/architectural’ progress.
How would you approach these problems?
Thanks a lot!
In Scrum, each sprint must deliver an increment of value, no matter how small. Most of the effort in an early sprint might indeed be expended on architectural foundations, but some value must be provided to the Product Owner. Often this value takes the form of a "tracer bullet" user story which validates architectural assumptions by testing from top to bottom, along with all of the qualities (integration, testing etc) that are appropriate for a "Done", potentially releasable increment. This may be a very narrow story, and different to any which have currently been framed.
Thanks Ian. I suppose the key line there "provide value to the Product Owner" rather than "business" (even if it's provided indirectly to the business).
I've never seen the "tracer bullet" idea before in Scrum. What would an example of that be? Is this where a User Story can be written more as a technical task to start building the architectural foundations of the system?
Think of it as a narrow scenario rather than as a task. See:
http://www.gettingagile.com/2007/10/22/research-spikes-tracer-bullets-o…
This principle is also sometimes known as a "sliver" or as "vertical prototyping". It is an old development concept and not uniquely an agile one.
The important thing is to make sure that the development and deployment pipeline is fully exercised by the scenario, including integration and testing. A good tracer bullet will validate an architecture and the process for value release. It will allow more useful increments of greater scope to be delivered in the future, based on that proven release-quality design.