As we've discussed in this blog recently, "agile" development doesn't mean "chaos," although it may seem that way to businesses that take a shot at adopting the development process.
Agile, stated simply, is an approach to development that breaks what otherwise would have been major projects under waterfall and other dev methodologies into smaller chunks. In Scrum and other agile philosophies, initiatives are addressed in basic units called "sprints," which have most of the aspects of larger coding blocks in other PM schemes.
Our partners at Info~Tech Research Group have developed an Agile Software Development Process Guide that serves not only as an introduction to agile concepts, but also a simple tracking tool to walk you through the five phases of a sprint-based project. The guide is available free to IT Business Edge members here in the IT Downloads library.
The guide kicks off with a general description of the five phases for each sprint:
You can see their circular relationship depicted in the image below.
The guide's checklist goes on to spell out more than 20 tasks that must be tracked, and assigns ownership of them to either the product owner (typically a line-of-business manager in Scrum methodology) or the Scrum master (aka, the project manager). As we said earlier, just because you are "agile" does not mean you don't have structure. In fact, in many ways the rapid pace of agile requires more immediate attention to process than waterfall - you have a daily Scrum to make sure things are moving smoothly.
Some of the tasks listed in the guide will sound very familiar; some are agile-centric terminology for describing basic steps in all dev methodologies. For example:
Project Initiation > Define backlog stories derived from epics: This is agile's version of a high-level business requirement. Basically, a Product Owner conducts interviews with stakeholders about their goals for the product. The results take the loose form "As a <ROLE> I want to <ACTION> so I can <PURPOSE>." From these stories, as they are called, Dev can develop functionality plans and Acceptance Test Criteria.
Sprint Planning > Define "done" for each story: It's important to note that while Product Owner is involved in scope discussions, the Scrum Master (PM) and QA work directly with Dev to ensure that scope and acceptance levels are understood from the onset.
Demo > Execute Demo: Demos are essentially the "showtime" for agile projects. In the absence of detailed mock-ups and specs, the Demo is where the tech team determines if the delivered product meets expectations. So, you better get your "stories" straight before digging into your sprint.
Even in agile, planning is key.