Agile, since it’s inception, was designed to deliver business value quickly and more often. Within Agile, business value is delivered through iterative defining of business requirements, paired testing, design and development, and continuous integration. However, the most commonly used Agile implementation, SCRUM, does not lend itself easily for shorter duration projects. When you are faced with project durations of less than 10 weeks, you will often find that you do not have time for Sprint Planning, Story Grooming, Story development, or Sprint-End Retrospectives. All of these ceremonies are important, but following all of them will take up important development time.
Introducing Agile Quick Hit
“Agile Quick Hit” is a process designed to support short duration projects, such as those that are between five and ten weeks in duration. It takes the Sprint Planning, Story Development and Story Grooming Ceremonies, then merges them together, and moves them to the front of the project in a “Kick-Off Ceremony.” The Sprint-End Retrospective is moved to the end of the project and is called a “Project-End Retrospective.” Stories take on a new life as “Epic Milestones” and “Iteration Milestones,” while tasks remain the same. There are a few other minor modifications to the standard SCRUM process, which is detailed below.
The Kick-Off Ceremony takes place before the start of the project. During this ceremony, the team will go over the project requirements and define what the Epic Milestones are, in order to complete the project and fulfill all the requirements. Epic Milestones can be related to a “feature story” in standard SCRUM. The difference between an Epic Milestone and a feature story is in the amount/level of details. In Agile Quick Hit, the Epic Milestone is a milestone defined to track progress to deliver a major requirement in the project. For example, the team may define an Epic Milestone as “UI Shell with placeholders for navigation, main body, header, and footer controls.”
Break down your requirements so that you can complete a single epic milestone per iteration. Iterations will be identified as “lasting for one week.” If you have a six-week project for example, then you will have a total of six iterations and six Epic Milestones. Each Epic Milestone will be prioritized based upon the order of completion to meet the project requirements. Epic Milestones can be identified on the team board with a large sticky note labeled with “Epic” as its identifier.
For this process to be successful, it is imperative that the project requirements are established before the Kick-Off Ceremony and any dependencies are defined and accounted for during this ceremony, along with any questions that arise.
At the start of the first iteration, the team will take the Epic Milestone identified, and the define Iteration Milestones needed to complete the Epic Milestone. The Iteration Milestones can be related to stories in a standard SCRUM. These will be identified on the team board with large sticky notes. The team will then break down each Iteration Milestone into standard tasks and identify them on the team board with standard sticky notes.
The team board can be broken down into meaningful, vertical swim lanes. Following the standard of having a “Dev”, “QA”, “Done” is recommended for the first iteration with the team, and adding more swim lanes as needed.
The first swim lane of the team board should be titled “Milestones.” This is where you will keep your iteration’s Epic Milestone and the defined Iteration Milestones. The team board will also have horizontal swim lanes, one for each Iteration Milestone. When moving your tasks through the board, keep the task in a horizontal line with the related Iteration Milestone. Once each task has been completed and verified by the QA process, move the task to the “Done” lane. Upon completion of all tasks for an Iteration Milestone, move that milestone to the “Done” lane along with all the related tasks. Once all Iteration Milestones have been completed for the iteration, move the Epic Milestone over to the “Done” lane.
The QA process will follow the standard SCRUM QA process, with the exception that all the test cases will be created during the first iteration and have their own Iteration Milestone and tasks for tracking.
The Iteration will also follow standard SCRUM daily standup ceremony for daily planning. If there are any blocks brought up during the standup, that block will need to be on high priority for the team to resolve for the iteration and project to be successful.
Iteration Demos should take place on the last day of the iteration and be open to all stakeholders for the project. After the demo has completed, the team should identify the next Epic Milestone’s Iteration Milestones and tasks.
The final ceremony for the Agile Quick Hit process is the Project-End Retrospective. This will follow the standard SCRUM retrospective ceremony with the addition of any remaining project deliverables being delivered and signed off. During this retrospective, it is important to take note of any areas for improvement for the process, and identify action points for implementing the improvements.
Call to Action
The Agile Quick Hit process has been a passion of mine and I have worked with two teams in defining the process and using the process to deliver the project. We have made adjustments along the way to bring it to its current state. My call to action is a request for others to use the process and comment back on thoughts and necessary changes.
This article was previously published in the SogetiLabs Blog
David Yancey (@DavidYancey), having 19+ years of experience in web development, joined Sogeti Dallas in July of 2010 as a Manager Consultant specializing in .NET Technologies with a focus on Web Architecture and Design. Through his efforts as a Test-Driven Development advocate and Agile Practitioner, he quickly became recognized as a software craftsman with in the Application Development and Integration practice. More on David.