Definition of legacy code: Old, onerous, and orphaned code base that is an obstacle to workflow and has octopus-like tentacles reaching into other systems.
The team was working with a legacy system. The batch jobs required to test the system typically took a day or three to run, depending on resource demands. We were moving from four-week sprints to one-week sprints, following Jeff Sutherland’s “Shock Therapy” guidelines. Our project goal was to modernize and expand the capabilities of our legacy system to support an under-construction online system for internal and external customers. I was stepping in as interim ScrumMaster for the first few weeks of the project.
The team members were adamant that one-week sprints couldn’t be done—not with their legacy code. The sticking point, obviously, was the testing turnaround on the batch jobs. “It is what it is” was the team motto. After a few discussions, in which the team members repeatedly explained to me why the dozen of testing mechanisms typically used in similar situations would not work here, I asked two of them to join me in the chief architect’s cubicle.
I sat down next to the chief architect’s desk while the others remained standing. Again, the chief architect (CA) explained how there was no way around this barrier. I smiled and stayed in my seat; I was not leaving. Eventually, the CA suggested using a “materialized view.” I should note that the team had rejected the concept of “snapshots” previously. The word “snapshot” is synonymous with a materialized view. Snapshots are just a subset or summary of the database at a specific point in time that can be used locally. Not only do snapshots have the advantage of being totally within the team’s control (no queuing), snapshots can omit vast pieces of the database that are irrelevant to the work at hand.
One of the concerns the team members had was that the database administrator (DBA) wouldn’t be able to create snapshots for them; they couldn’t expect that of him. The CA told the team “no problem” and suggested we all go talk to the DBA right then. We worked out the schedule for requesting the materialized views, and voila—the team could test the first couple of versions of their queries in a matter of minutes, instead of days. We still had to allow for a test using the entire database, and snapshots were only an intermediate step to solving the real problem in the system. However, we had taken the first step in proving “it could be done” and that we could change the ways things were—we had power.
Still, the amount of work in the product backlog was daunting. Even with a faster testing cycle this was going to take some time. However, the team members were optimistic that they could deliver on time. After a few sprints, we were able to project a velocity range. With our experience in mind, we estimated the entire product backlog of user stories using the White Elephant-sizing method.
Also known as the Yankee Swap, the White Elephant method is a structured process where team members individually read a user story and using structured speech announce, “I think this story is (either) ‘small,’ ‘medium,’ ‘large,’ or ‘extra large’ because...” They then place the story on the wall in the appropriate size bucket. No one is allowed to comment. However, if someone disagrees with a placement, then when it is that person’s turn, that team member is allowed to move the story—again using structured speech to justify the new placement. The game is over when every user story is placed and there is a round where all team members affirm that they are content with the placement of each and every story. Each bucket size is assigned a story point number value. Using team velocity, we forecast how long it will take to complete all the stories in the product backlog.