The Agile Process in PMP
Before we get into the Agile Process, you should understand that the two most famous agile methods that are being followed are scrum and extreme programming.
Both methodologies follow a very similar process but use slightly different terms.
For example, in scrum, the work that is getting done is called a Sprint, while in XP it is known as an iteration.
PMP Agile Terminology
Here is a list of terms we will be using as I described the agile process:
- Product owner. The designated person that represents the customer on the project
- Agile project manager/scrum master. Manage is the agile project. Primarily acts as a facilitator.
- Product backlog. The project requirements from the customer
- Sprint planning meeting. The meeting carried out by the agile team to determine what features will be done in the next Sprint.
- Sprint backlog. Work the team selects to get done in the next Sprint
- Sprint. A short iteration where the project teams work to complete the work in the Sprint backlog, ( one to four weeks typically)
- Daily stand-up meeting. A quick meeting each day to discuss project status is, led by the agile project manager. Usually around 15 minutes in length
- Sprint review. An inspection done at the end of the Sprint by the customers
- Retrospective. Meeting done to determine what went wrong during the Sprint and what went right. Also collect lessons learned for the Sprint
- Release. Several sprints worth of work directed to operations for possible roll-out and testing
Here is a brief overview of what the agile processes
- The customer/product owner determines the requirements they would like to get done in the project. These requirements are stored in a document called the product backlog.
Learning Today Leading Tomorrow!
All Courses for just $15/month with a simple annual payment
PMP Agile Process – Product Backlog
The product backlog contains a list of all requirements that are needed for the project and is prioritised based on value by the product owner.
Only the product owner can prioritize the product backlog. This means that the items at the top of the product backlog would be considered more valuable to the organization than items at the lower part.
The top of the product backlog will have the accounts receivable section as being the first item.
For example, a company may prioritize completing the accounts receivable section of an accounting software over accounts payable. Once the product backlog has been prioritized, the agile project team then does a Sprint planning meeting where they will determine what work they will do from the top of the product backlog in the next Sprint.
They will then store these items that will be getting done in the next Sprint in another document called the Sprint backlog.
Keep in mind, a Sprint is only one to four weeks’ worth of work.Dave Litten’s key Quotes for PMP Agile Process
After the Sprint backlog is complete, the team will then execute the Sprint and begin the actual work. It is during the Sprint that that seam will actually code the application or build the server.
During the iteration, the team will meet once a day to conduct what is known as a daily stand-up meeting.
This meeting will have all team members answer three questions, what did you do since the last stand up, what will you do between now and the next stand up, and what impediments or roadblocks are you facing currently.
It is important to understand that while the Sprint is going on, there should be no changes to the team members. This will ensure that the team can work at a sustainable pace.
Adding or removing team members during the Sprint could lead to the pace slowing down, as new people will need to learn procedures and the way that they operate.
PMP Agile Process – Sprint Completed?
After the Sprint is completed, the customers will attend a Sprint review meeting. In this meeting, the customers will evaluate the work that has been completed during the Sprint and give their feedback.
The customers may say things such as the product is great so far or may outline what is wrong and what needs to be fixed.
After the customer has given their feedback, the team will then meet in a meeting that generally lasts about two hours and conduct a retrospective meeting.
In a retrospective, team members will outline what they did correctly in the previous Sprint and what they did wrong. They would analyze things during the Sprint that may have led to a defect and things that may have led to overcoming defects.
This way, in the next iteration, they will know what to do to prevent these things. They will do things such as creating a list of things to do more of and things to do less of. Once the retrospective is done, the team will then go back to the product backlog to complete the remaining work.
Once the team has completed the first Sprint, they may have a partial product that they could release all the way to production.
While this may happen on a few projects, in general, it will take a few sprints before the team is able to release a product that is usable by the customer.
So, it is not uncommon for a customer to wait anywhere from two to four sprints before they are able to get a minimal viable product (MVP).
This is a product that may not have all the features but is still usable.
The release of a partial product all the way to the customer is known as a release.
Release is generally made up of one or numerous sprints, it just depends on the complexity of the product that is being created.