The Certified Associate in Project Management (CAPM)® exam is changing to account for updates to A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Sixth Edition. All exams will be for the Sixth Edition as of May 21, 2018. From March 12-30 and March 31-May 20, candidates can take the Sixth Edition version of the English language exam and save money on their exam fees. Learn more at PMI.
The Certified Associate in Project Management (CAPM)® certification is for project managers who want to show their credibility or start taking on more project management roles. Anyone who has a secondary degree and at least 1,500 hours of project team experience, or at least 23 hours of project management education, is eligible.
These requirements are less strenuous than the Project Management Professional (PMP)® which requires both experience and education hours. The CAPM certification exam also has fewer questions than the PMP exam, takes less time, and draws solely from A Guide to the Project Management Body of Knowledge (PMBOK® Guide). In contrast, the PMP exam covers both the PMBOK® Guide and situational questions where project managers must draw from their experience to determine the best answer.
While the CAPM exam is not as involved as the PMP exam, it is not an easy exam. Candidates need to develop a strong study plan and study routine. In addition, they need to develop strategies to manage their confidence on the day of their exam. In our experience, candidates who cannot devote regular time to study or manage their time and confidence during the exam are more likely to fail. These tips help you prepare for and take the exam with confidence.
As the workplace becomes more global, managing virtual teams is more of a norm than an exception. Virtual teams present unique team communication challenges. We have put together the top five common communication challenges with virtual teams and included tips to help you overcome them.
We have seen many times that successful project delivery comes less from having all the bells and whistles and more from effectively executing key processes. In previous posts, we have presented a series of eight project management processes that greatly increase the chance of project success on small- to medium-sized projects when executed properly. We have also presented ways to achieve similar results for smaller or larger projects, with a lesser or greater degree of complexity, number of full-time team members, and duration. These results are possible through using a tiered approach to project management rigor.
Agile teams often face a challenge in determining how long their iterations, or sprints, should be. If sprints are too short, teams can get bogged down with prep work and overhead. In contrast, maturing teams may struggle to deliver working software in the demanding timeframe. However, longer sprints may also lead to wasted time for questionable added value.
On a project, risk management means identifying, planning for, and monitoring for risks that threaten to derail the project’s schedule, budget, or scope. In agile, the risks threatening the scope take on greater dimension, since the scope is flexible. Risks on agile projects hinder the ability to deliver value to the customer by keeping the team from being able to accomplish key tasks. In this blog post, we will look at the risk-adjusted backlog and how to apply it at each level of the agile project.
The release burnup chart shows an Agile team’s progress toward their release goal by identifying the work they have completed, or “burnt up.” The release burnup chart builds on the sprint burndown chart, which shows the team’s progress toward their sprint goal by identifying the work that has “burnt down,” Burnup charts can show the effect of scope changes with greater clarity than burndown charts can; they can also be stacked to show changes from one sprint to the next. With these added features comes one precaution: burnup charts are often harder to read than burndown charts. In this post, we will discuss ways of creating burnup charts, how they would be used, and best practices and pitfalls.
The sprint burndown chart is a key tool to monitor the progress of your team during a sprint. The chart measures remaining work against time. The sprint burndown chart’s primary purpose is to show whether the team will be able to complete the sprint work. Beyond this primary purpose, the sprint burndown chart can also expose the reality of how your team is performing.
Resource allocation is a critical process on both Agile and traditional projects. Even the best-planned projects can’t be carried out if there are not enough people to do the project activities, or if they are too busy. Agile values teams delivering working software at the end of each sprint, collaborating closely with the customer, and managing their own output. To accomplish these goals, the team needs must be able to accurately assess its own capability based on reality rather than best guesses. The sprint capacity planning sheet is a powerful tool for teams to discover their capacity and deliver more realistic assessments of their ability to execute what is needed to finish a sprint.
Backlog management in Agile needs to occur at three levels. First, the product backlog contains the prioritized list of epics, features, stories, and tasks. Second, the release backlog separates the features in the product backlog into time-phased chunks, with the first release containing as many high-priority features as possible in a working piece. The granularity differs in that the release backlog only contains prioritized and estimated stories. Finally, there is the iteration or sprint backlog (hereafter referred to as sprint backlog), which is organized into stories, broken down into tasks and estimated in terms of hours, that the team can implement within the span of each sprint. In this post, we describe the sprint backlog and best practices and pitfalls for its use.
Strong communication between the customer and the project team is a fundamental ideal of Agile that helps to produce quality results that the customer can use right away. For strong communication to happen, there needs to be common ground; otherwise, the two sides are coming from different cultures and speaking what may sound like two different languages, and this makes communication difficult. User stories fill this gap by framing requirements in a way that facilitates communication between the customer and the project team, and for this reason, they are a critical piece of any Agile project. Keep reading to learn more about what a user story is, how it is structured, and how to write one effectively.