Freigeben über


One Story At A Time

Hey everyone, this is Marius Grigoriu, PM leading the Risk Tracker and Security BI projects and portal and notifications components. One of the challenges we encountered on our path to Agility was that our testers were getting squeezed at the end of each sprint. What I heard from our testers was that we could simply not perform all the desired testing and fixes in the last week or a four week sprint. This was a sign that we were doing something incorrectly. I started digging into the problem and asking questions. What I was told was that we couldn’t drop to test earlier in the cycle because code was still in progress or undergoing unit testing by the authors. I looked at our task list and found that all of our stories for the sprint were started, but none were fully completed (for us that means tested). This was actually a frightening discovery. We ran the risk of having nothing ready for our sprint demo if any last second issues were to appear!

As we planned the next sprint, I convinced my teams to try something different. What we did was fully plan and assign tasks for a story before moving onto the next. Rather than having only one developer per story, we applied the entire team to each story. If our schedule were to slip or something else go wrong, chances are that we would still have at least one story ready for demo. Planning our sprint this way showed us that we also had some bottlenecks in test. Although we do have automation in our regression suite, we found that our drop and deployment procedures were taking too long. Now that we were dropping and deploying several times per sprint, and often a few times per day this source of pain became obvious.

Our next step in continuous improvement will be to automate our deployments to test environments. I can see where this is heading, but don’t tell my team this. My guess is that next we will want to start connecting our builds jobs and automated tests on either end of the deployment automation to get a daily automated test report. And as pressure grows for frequent rollout to production and installation errors due to manual deployments, I could see us eventually making an effort automate ourselves all the way to production.