Tales from the Trenches: Conquering the Challenges of Transforming to Agile

[article]
 
 

Agile Story Template

Story Business Status:

  • This story has been discussed and vetted with key stakeholder(s) for completeness

OR

  • This is a draft story that requires stakeholder review for completeness

User Story:

  • This should describe the high- level business situation and players involved.   Example: As a [role], I want to [action] so I can [outcome]. Identify the business impact if this requirement is not met (operational execution, support, reporting/inspection, productivity, adoption, financial). Try to give examples of typical business scenarios.

 

High- Level Requirements:

  • High-level requirements (grouped logically with three key points identified: 1. user/group, 2. process/action, and 3. vision)
  • If applicable, list any constraints.: Include constraint items such as required hardware, required software, required third party software, etc., that the user must have to use the functionality in this business design. Include set- up or usage constraints for implementing the new functionality included in the business design.

Assumptions:

  • List  assumptions of how this functionality or process should or should not behave.

Conditions of Acceptance:

  • Acceptance criteria should be detailed enough to define when the user story is satisfied, yet not so detailed as to quash collaboration.
  • Acceptance criteria answer the question, “How will I know when I’m done with the story?” Test cases answer the questions, “How do I test?” and “What are the test steps?”   

High- Level Test Case:

  • List the test cases that will ensure results will meet expectations. This also will help the IT team, as they may not think of all the possible business scenarios.

Mock- Ups/Attachments: Reference these in the description so that people are aware of them. Add to stories where relevant.

 

 

Challenge 2: Timing and the Globally Distributed Team
We had numerous challenges in this area:

  • Determining sprint length
  • Aligning schedules for vacations, holidays, quarter-end moratoriums, etc.
  • Globally distributed teams
  • Incorporating integrated user acceptance testing

We started with two-week sprints but ran into the obstacles of holidays, moratoriums, story writing, team member availability, porting, and sprint planning activities. It became almost impossible to complete everything in a two-week timeframe and at the same time achieve a meaningful level of development.

Agile recommends collocation of the team; when this is not possible, a lot of timing obstacles arise that must be carefully addressed. In today’s world, many organizations do not have the luxury of putting everyone in the same room. Consequently, things like optimizing the lag time between time zones, ensuring timely responses to issues, and facilitating handoffs become more challenging.

Both projects wound up with three-week sprints. This allowed some flexibility when dealing with holidays, moratoriums, and other scheduling obstacles.

Testing is included in our story definition of done; this includes user acceptance testing (UAT), not just developer unit testing. And we’ve found there is a lot of value in performing thorough regression testing each sprint. In the Integrity project this is handled by both automated testing and manual testing by developers in the last couple of days of the sprint. This has recouped time later on in the reduction of defects found in shipped code. It also removes the need for formalized end-game UAT, as we are getting that input on a sprint-by-sprint basis.

User Comments

1 comment

About the author

Alison Jacques's picture Alison Jacques

With over 20 years in both software development and IT project management, Alison Jacques brings a wealth of experience and learning to bear on challenges in the PM discipline. In addition to being a practicing PM, Alison has tailored process methodologies from CMMI to waterfall to Agile at several companies. Of latest interest to her is the shift from waterfall to agile methodology and how PMs can adapt and leverage this new approach to improve project delivery. Alison holds a bachelor's degree in philosophy from Georgetown University and a graduate management certificate from Babson College. She was certified as a PMP in 2005 and became a CSM in 2012. She is currently working on her PMI-ACP.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!