Background: Agile is an approach to software development, alternative approaches are Waterfall, RAD, or Extreme Programming. Agile break the tasks into small increments (aka Sprints) with short time frames (from one to four weeks). All project members (business and Tech) work closely together and sit in the same location with daily meetings to assess progress -the team is referred to as a Scrum. At the end of the iteration a working product is demonstrated to stakeholders.
Agile uses Storyboards to help all the project members and stakeholders understand what's the goal. In Agile development, a storyboard looks less like a cartoon panel and more like a series of columns (each column represents a status for example the first column in 'Not Started', the next column is 'In Progress' then Complete etc). Each column is filled with colored squares of paper. Typically, the columns are laid out on large format paper or whiteboard. Each column represents a status and user stories are dragged to a new column when the status of the user story changes (i.e. moves right to completed).
An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories. It may take several sprints to complete an epic. An epic can span more than one project, if multiple projects are included in the board to which the epic belongs
Unlike sprints, scope change in epics is a natural aspect of agile development. Epics are almost always delivered over a set of sprints. As a team learns more about an epic through development and customer feedback, user stories will be added and removed to optimize the team's release time. This is the unique freedom a product owner gets with an agile framework, because it ensures the development team is working on the most important things.
Burndown charts can also be used to visualize epics, which keep teams motivated and the executive stakeholders informed. A good epic burndown chart shows the agile nature of development. It's clear how the team is progressing as well as where the product owner added and removed user stories. Having these data points clearly visible keeps everyone on the same page and facilitates open conversation about the evolution of the product and completion forecasts.
Ensure there is a clear understanding of what is the Agile methodology includes and does not include. There are many variations of agile and different organisations and teams within organisations have a range of views of how to apply agile. Therefore ensure all the team understand what the agile methodology is and have been trained .
Ensure the software development project documents as it progress and captures all the decisions and requirements as they evolve from the stakeholder/customer. Agile can require a lower level of documentation, however in reality what this means in there's not a large requirements document and technical specification at the beginning of the project. Therefore Agile actually does require a significant amount of document (project artifacts), it's just done in iterations instead of all up front.
Review the approach taken and ensure the software development project is not implementing a combination of Waterfall and Agile - termed 'Wagile'. This can occur when member of the project team start reverting back to Waterfall as they are not familiar with the traditional Waterfall Software Development Lifecycle (SDLC).
Check the Agile project does sufficient testing and has a point in the iterations when it will do a risk analysis and determine if security testing is requried (for example Penetration Testing) or secure code reviews. It's essential these testing steps are not overlooked in the drive to get the functionality working and go-live for the stakeholder/customer.
Assess how the Agile project has estimated the time taken to complete each iteration, for example what level of analysis in the project manager do to determine the duration required and number of resources. This should be clearly documented. Every member of the team should be involved in some extent in the estimating.
Check each Scrum team should not exceed more than approximately 9 team members.
Check iteration should not be more than 4 weeks in length.
Ensure the whole team participants in the daily Scrum meeting.
The Agile project should have a clear definition on when the iteration is completed , known as a Definition of Done (DoD). For example, what is the critical success criteria for each iteration.
Check each Sprint has developed a list of activities /deliverables (referred to as Tasks in Agile) that need to be completed. This is referred to as a 'burn-down list' as the Sprint checks off each deliverable as it is completed.
Ensure the the roles and responsibilities of the Agile project as clear, for example a Scrum Master (aka Team Lead) and a Product Owner (aka Customer).
Determine how the Agile project to recording issues and risks to the project (referred to as impediments in Agile).
Ensure if the Agile project is a large software development that there is a Scrum of Scrums. i.e. the Agile project will be divided into multiple Scrums (of approximately 9 team members) and the Scrum Master of each Scrum will attend a Scrum of Scrums.
Determine how dependencies are recorded and tracked on the Agile project.