What is Agile Project Management?
Agile is a method of project management that utilizes an iterative and incremental approach to software development. It places its emphasis on rapidly delivering functional components of a product in two week cycles called sprints.
In Agile, work goals and deliverables are defined by the team before the start of each sprint (a two week period in which a specific project feature is completed, tested and delivered). At the end of the sprint a tested and approved working component of the product is delivered, and then the sprint process starts again with a new deliverable. This continues until the product is complete.
One of Agile’s biggest strengths is its flexibility and preference towards constant, timely feedback. As a project develops, members of the development team request and collect reviews, suggestions, and feedback on the latest iteration and how the next one can build upon it.
Some additional benefits of Agile include:
Agile Projects are Nearly Failproof:
Agile eliminates the chance for projects to fail completely. By delivering usable pieces of the product at the end of every sprint and receiving feedback on those pieces, you don’t run the risk of spending hundreds of hours (and even more dollars) building a flawed product. And because you are delivering usable features at the end of each sprint, you won’t find yourself with a pile of unusable code, regardless of what may happen in the future of the project.
Stakeholder Involvement and Satisfied Clients:
Agile relies on a high level of executive involvement throughout the project, which is mutually beneficial in many ways.Because Agile allows for quick cycles and consistent feedback, the development team is able to make changes and adjustments sooner rather than later, helping to ensure they are always on the right track - even if the requirements shift.
Additionally, rather than requiring the client to wait until the entire product is complete, Agile allows the client to assess the work being delivered at the end of each sprint, meaning that changes aren’t nearly as costly or time consuming as they would be when utilizing other project management methods.
Better Products:
In Agile development, testing is conducted during every sprint, allowing defects and other potential usability problems to be identified and fixed immediately, helping to maintain the quality of the product throughout its development.
How Do You Run an Agile Sprint?
A Sprint is a two week period during which your team completes a set amount of work. Sprints are at the very heart of Agile, so getting them right will help your team build better products with greater ease and speed.
When beginning a project you’ll be starting with a couple of important preliminary sprints before getting to your Agile Scrum Sprints. These initial sprints include:
1. The Onboarding Sprint
This sprint is about getting everyone on the same page and setting your team up for success. It should be spent assigning roles and responsibilities for the team and solidifying the projects:
- Budget
- Timeframe
- Metrics for success
This Onboarding Sprint doesn’t need to be an entire two week sprint, but should be time boxed in typical sprint fashion to ensure that these important foundational elements are completed.
2. Roadmapping Sprint
This sprint is when you’ll generate your user personas, user journey map and your tech stack. By the end of this sprint your team will have drafted and prioritized the first batch of user stories.
Executive involvement in this phase is mandatory as execs will be trained on what KPIs and metrics should be used to measure progress. To help accommodate busy schedules, it's a good idea to plan your future review and vision alignment meetings at this time.
Once you’ve completed both of these initial sprints and have a backlog of user stories created and prioritized you’re ready to begin your Agile Sprints.
Each of your two week Agile Sprints will include the following:
1. The Sprint Planning Meeting
During these meetings, the team looks at the project backlog (a list of all the things that need to be done within the project), and agrees upon a set of items to be completed during the week by playing a game called “Points Poker”.
To play Points Poker, each team member holds a numbered set of cards and, as each item in the backlog is read out, puts down the card with the number of points they believe the item should be valued at, based on its complexity.
The team then reaches a consensus, and the backlog item receives the point value agreed upon. The game of Points Poker continues with more backlog items until the number of points equals the teams velocity, which is calculated by adding the average number of points each individual team member is able to complete in a given week.
Each task is then assigned to individual team members, who are then responsible for their completion. T
During each sprint planning meeting you’ll need to:
- Identify which features from the product backlog make most sense to work on.
- If necessary, split those features into multiple, smaller tasks for completion.
- Evaluate whether the team has the capacity to complete the work planned for the iteration. Points Poker is helpful in achieving this.
2. The Sprint Kickoff meeting:
This meeting should occur just after the sprint planning meeting and include key individuals and the client/stakeholder. The goal of this meeting is to communicate your plan for the coming sprint to the client and to answer any questions they may have.
3. The Sprint!
At this point your team is ready to work on completing each item in the sprint backlog. For an item to be complete, it must be coded, tested and documented.
4. Daily Scrum:
This is a 15 minute long internal meeting focused on creating a plan for the next 24 hours. During this meeting each team member should answer the following questions:
- What did you do yesterday?
- What will you do today?
- What is blocking your progress?
5. The Sprint Wrap Up:
At the end of every sprint you should hold a Sprint Wrap Up meeting that includes the entire team and clients/stakeholders.
During this meeting the work that has been completed during the sprint is presented, followed by client/stakeholder feedback. Changes to the product backlog, in relation to the feedback received, should be discussed at this time.
In addition to the bread and butter meetings mentioned above, you’ll also want to hold the following meetings on a regular basis:
1. Stakeholder check in:
These meetings are held monthly and include the internal team’s leads/managers and the client/stakeholder. Stakeholder check-ins are a higher level project health check, during which the timeline is reviewed, issues are discussed and any concerns are voiced.
2. Backlog Refinement:
This should take place at the beginning of every sprint and include the entire internal team. The purpose of this meeting is to collaboratively inspect the product backlog to ensure it is clean and well organized. This involves removing duplicate tickets and ensuring that all the work that needs to be done is represented in the backlog.
3. Vision Alignment:
This meeting should be held every three sprints, and involve project leads and the client/stakeholder. During this meeting the work that has been done on the project thus far should be assessed by comparing it to the benchmarks established in the project roadmap. Any project issues should be discussed, and the roadmap should be adjusted based on new inputs and strategic goals
4. Retrospectives
These can be held at the end of every sprint. Retrospectives involve candidly discussing areas of the project that are going well and areas needing improvement, with the intention of generating ideas for improvement in the next sprint, and for the teams general process as a whole. Take a look at our article on Retrospectives for fun and helpful Retro agenda ideas!
