This is the induction of the programme, including the programme plan and expectations. 

Please, when you watch it, report to APTEM that you have watched it. 

see attached

Once you have finished reading this chapter, please log your completion on APTEM. The suggested time for this activity is 2 hours. 

This is the introduction and the list of KSBs (Knowledge, Skills, and Behaviours) for Chapter 2: Project Context.
Chapter 2 will be delivered over three lectures during May, covering the following topics:

• What is a project?

• The differences between a project, a programme, and a portfolio

• Project initiation documents

This is not mandatory but will supplement your learning. 

This is not mandatory but will supplement your learning. 

This is not mandatory but will supplement your learning. 

This is not mandatory but will supplement your learning. 

Project Initiation Documents and Strategic Alignment

Introduction

Every project exists to support an organisation’s goals, so it’s essential to start off on the right foot by aligning each project with the broader corporate strategy. Good project management ensures that a project’s objectives line up with the critical goals of the business. In practice, this alignment is achieved and maintained through a set of key project initiation documents. These documents not only kick-start the project but also serve as living references that keep the project tied to the organisation’s strategic objectives throughout its life cycle.

This guide will explore each of the main project initiation documents – the Business Case, Benefits Management Plan, Project Charter, Project Management Plan, Project Success Measures, and the context of Organisational Goals and Strategy – explaining what each is, how it supports alignment with corporate strategy, and how it is used throughout the project’s life cycle. We’ll illustrate each section with clear examples (drawing on UK case studies such as Crossrail, HS2, and NHS projects) to show these concepts in action. The content is written in a conversational, course-friendly tone, suitable for Level 6 Project Controls Professional apprentices preparing for certifications like PMP, APM’s Project Management Qualification (PMQ) or Professional Qualification, and even APM Chartered status. By the end, you should have a solid understanding of how these documents work together to ensure that projects not only deliver on time and budget, but also deliver real strategic value to the organisation.

Business Case

What it is: The business case is the foundational document that justifies the project’s existence. In simple terms, it explains why the project should be done and what value it will bring. According to the Association for Project Management (APM), “a business case provides justification for undertaking a project, programme or portfolio. It evaluates the benefit, cost and risk of alternative options and provides a rationale for the preferred solution”. In other words, the business case lays out the problem or opportunity the project addresses (the strategic context) and demonstrates that the proposed project is the best way to invest the organisation’s resources for maximum return. It typically includes an appraisal of options (including doing nothing), an analysis of costs versus benefits, key risks, and how the project will be managed to deliver the benefits. All projects – big or small – require some form of business case to demonstrate their value and viability.

Strategic alignment: One of the first sections of a robust business case is the strategic context or strategic case, which explicitly links the project to the organisation’s high-level objectives. This is where the business case answers the question: How does this initiative support our corporate strategy? For example, a business case for a new high-speed rail line (like HS2) needed to show how the project would further national transport and economic strategies – in fact, the HS2 Phase One strategic case argued that HS2 was “the only viable long-term solution to overcrowding on the rail network”, directly tying the project to the strategic goal of increasing rail capacity and regional connectivity. Similarly, the Crossrail business case was built around London’s strategic transport needs and economic growth plans. The business case went through multiple iterations between 2003 and 2010 as the project evolved, each time ensuring the project still aligned with current government transport policy and provided value for money. This iterative development (following HM Treasury’s “Five Case Model” of Strategic, Economic, Commercial, Financial, and Management cases) helped keep Crossrail’s objectives aligned with both national and London-wide strategies over the years. By articulating a compelling case for change in strategic terms, the business case secures executive buy-in and funding for the project on the grounds that it will advance organisational goals.

Lifecycle usage: The business case is first developed in the concept or initiation phase of the project (often even before a project manager is appointed), and it plays a pivotal role in the go/no-go decision. The project sponsor – a senior figure who champions the project – typically owns the business case. In fact, UK guidance from the Infrastructure and Projects Authority (IPA) notes that the sponsor “owns the business case and secures the funding for the project,” ensuring “the project remains strategically aligned, viable and delivers its whole life value”. Once approved, the business case triggers the formal start of the project. But it’s not a one-and-done document; a good business case is a living document that is reviewed and updated at key stage gates throughout the project lifecycle. At each major decision point (for instance, moving from design into construction, or responding to significant changes), the business case is revisited to verify that the project still makes sense and still aligns with strategic objectives given the latest information on costs, schedules, and risks. If the situation changes – say costs balloon or the strategic context shifts – the business case may be revised, or in extreme cases, the project could even be paused or stopped. This governance process ensures the project continuously earns its keep by staying aligned to the organisation’s strategy and delivering intended value. For example, as Crossrail’s costs and timelines were refined, updated business case reports in 2010 and 2011 reassessed the project’s value and alignment with transport needs. The business case remains a reference point even during execution: the project manager and team should be aware of the promised benefits and strategic objectives in the business case so they don’t lose sight of why the project is being done. In summary, the business case is the anchor for strategic alignment – from day one to final handover, it ensures the project is justified by and continually aligned with corporate strategy.

Practical example: Consider a National Health Service (NHS) project to implement a new electronic patient records system. The business case for such a project would outline how the new system will contribute to the NHS’s strategic goals (for instance, improving patient care quality and operational efficiency). It might cite the NHS’s Long Term Plan or digital transformation strategy, showing that the project supports goals like shorter waiting times or better data for decision-making. It would weigh the costs of the IT investment against the expected benefits, such as reduced administrative overhead, fewer medication errors, and improved patient outcomes. Throughout the project, hospital leadership would revisit the business case at approval points: is the project still likely to deliver the expected benefits within budget? If a particular approach turned out too expensive or a new regulatory requirement emerged, the business case would be updated to reflect a change in approach or scope, always checking that the project remains aligned with the overarching goal of better, safer patient care. By the end of the project, the business case provides the yardstick against which success is measured: did we achieve the benefits and strategic outcomes we set out to achieve? If well-managed, the business case for our NHS IT project will have served as a strategic guide star from initiation through to the point where the new system is in use and delivering real improvements for the organisation.

Benefits Management Plan

What it is: If the business case defines the why and what in terms of value, the Benefits Management Plan defines how those benefits will be realised and measured. In essence, this document lays out a plan for identifying, tracking, and achieving the benefits that the project is expected to deliver. A benefits management plan (often simply called a benefits realisation plan) will describe each expected benefit, how and when it will be delivered, and who is accountable for it. As one definition puts it, a benefits management plan “describes how and when the benefits of the project will be delivered and how they will be measured”. It typically includes a clear description of each benefit (e.g. “reduce operating costs by 10% within two years”), the benefit owner (the person or role responsible for ensuring that benefit is achieved – often the project sponsor or a business manager), the timeframe or milestones for realising the benefit, and the metrics or Key Performance Indicators (KPIs) to measure progress. It will also note any assumptions made (for example, “cost reduction assumes stable energy prices”) and any risks to achieving each benefit (for example, risk of uptake being slower than expected).

Strategic alignment: The benefits management plan is directly about strategy, because benefits are essentially the outcomes that contribute to strategic objectives. If a project’s benefits don’t align with an organisational goal, why are we doing the project at all? Thus, the benefits plan explicitly ties each project benefit back to one or more strategic objectives or KPIs of the organisation. We move the focus from just delivering project outputs (new systems, new buildings, etc.) to delivering meaningful outcomes that matter to the business’s strategy. For example, imagine a project in a UK local council to introduce electric buses. The business case might identify benefits like “lower carbon emissions” and “improved air quality”. The benefits management plan will take those and link them to the council’s broader environmental strategy (say, a goal to be carbon-neutral by 2030). It will state how emission reductions will be measured (maybe via tonnes of CO₂ reduced per year) and ensure that this aligns with national climate targets or local clean air objectives. In practice, a benefits-led approach to projects ensures that decision-making and planning always consider impacts on benefits – and thus on strategic goals – throughout the project life. The UK government even has formal guidance promoting this benefits-driven approach in major projects, to avoid the trap of delivering outputs that don’t actually translate into strategic value. In short, the benefits management plan is a key mechanism for alignment: it keeps everyone’s eyes on the prize (the strategic outcomes), not just the project’s deliverables.

A great illustration comes from the NHS again: In a hospital IT project, a benefit might be “reduce patient waiting times in the Emergency Department by 15%”. This clearly supports strategic goals around patient care quality and efficiency. The benefits plan would connect this to the hospital’s corporate objective of improving patient experience. By defining that benefit clearly and how it will be measured (perhaps average wait time in minutes before and after implementation), the project team and stakeholders maintain a line-of-sight to an organisational goal. If mid-project, a decision needs to be made (say, cutting a feature due to budget constraints), the benefits plan helps gauge how that decision might affect the strategic outcomes. It essentially asks, “Will this help us deliver the promised strategic benefit?” If not, perhaps that feature shouldn’t be cut. In this way, the benefits management plan guides the project toward maximising strategic value.

Lifecycle usage: The benefits management plan is often developed early in the project (usually during project planning, after the business case and charter are in place). It draws heavily from the business case – after all, the business case lists the expected benefits that justified the project. Once created, the benefits plan becomes a tool for ongoing governance. During project execution, project controls professionals will periodically review the plan to ensure benefits are on track. Some benefits might not fully materialise until after the project is completed (for example, “increase market share by 5%” might only be verifiable a year after a new product launch). Therefore, the benefits management plan often extends beyond the project’s closure into the operational phase; it includes post-project reviews or handovers to those who will own the benefit in business-as-usual. In many organisations, the project sponsor remains accountable for tracking benefits realisation after the project team disbands. The plan might schedule benefit reviews at 6, 12, or 24 months after project completion to check whether the anticipated benefits (like cost savings or performance improvements) have been achieved, and to take corrective actions if not.

For example, consider Crossrail (the Elizabeth Line): years after the construction project phase, Transport for London and the UK government will be measuring whether Crossrail is delivering its intended benefits – such as reducing journey times across London, easing congestion on Tube lines, and boosting the economy in areas around new stations. A benefits management plan for Crossrail would have outlined those targets (e.g. expected passenger numbers, time saved per journey, economic uplift in local districts) and identified who in the organisation would track them once trains started running. Indeed, the Crossrail Business Case Update reports and the subsequent Crossrail Baseline Evaluation 2022 were essentially exercises in checking the real outcomes against the promised benefits. By having a structured benefits plan from the start, the Crossrail sponsors could keep the project aligned with the strategic transport outcomes that justified the £18+ billion investment. If any benefit was at risk (say predicted ridership was falling short), that would raise strategic questions: do we need additional initiatives to realise that benefit, or was our business case assumption flawed? Thus, throughout the project and into operation, the benefits management plan is a north star for ensuring the project’s value proposition (and strategic alignment) holds true.

In summary, the benefits management plan complements the business case by providing the detailed roadmap for turning project outputs into strategic outcomes. It keeps the team focused on delivering real value, and it provides sponsors and executives with confidence that the project’s contributions to corporate strategy will actually be realised and measured.

Project Charter

What it is: The project charter is a short, foundational document that formally authorises the project to begin. If the business case answers “Why do this project and is it worth it?”, the project charter answers “What are we going to do, at a high level, and who is in charge?”. A typical project charter will outline the project’s purpose, high-level scope, main objectives, key stakeholders, and designate the project manager with authority to spend resources. In fact, according to PMI’s PMBOK® Guide, a project charter is “a document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities”. In plain terms, it’s the piece of paper (or digital document) that the sponsor signs off to say “Yes, we’re doing this project, and Alice is the project manager, and here are the broad strokes of what we expect.” It may include a rough timeline or milestone plan and initial budget or resources, as well as any top-level requirements or success criteria. It’s often surprisingly concise (sometimes just a few pages), but it carries a lot of weight: it’s the bridge between the idea (business case) and the detailed planning to come.

Strategic alignment: A good charter explicitly ties the project to the organisation’s strategy, often by referencing the business case or strategic objectives. In fact, the charter is an ideal place to document the relationship between the project and the organisational strategy. For example, the charter will usually include a section like “Project Purpose” or “Business Need” – here it might state something like: “This project will implement a new online appointment system, in response to the NHS Trust’s strategic goal of improving patient access to services.” By articulating this, the charter makes it clear from the outset how the project supports corporate strategy. This linkage is not just for show; it helps the project team understand the bigger picture and thus make day-to-day decisions in line with that strategic intent. If scope questions arise later, referring back to the charter’s stated purpose can help decide what is in or out of scope based on whether it supports the strategic goal.

It’s worth noting that PMI and APM guidance both emphasise the role of the sponsor in ensuring the charter aligns with strategy. The sponsor (often a senior manager from the business area that benefits from the project) either writes or heavily influences the charter. They ensure that the project’s high-level objectives, as stated in the charter, are rooted in a genuine business need and strategic priority. In practical terms, one can think of the charter as the story of the project at its inception: why it exists (strategic rationale), what it aims to achieve (objectives and success criteria), who’s involved (key stakeholders, sponsor, PM), and what constraints or assumptions exist. For instance, High Speed 2 (HS2) – the UK’s high-speed rail project – would have a charter (or equivalent project initiation document) that clearly states the project’s vision (e.g. “to dramatically increase rail capacity and connectivity between major UK cities in support of the Government’s levelling-up agenda”). This one line encapsulates strategic alignment: it ties the project to national policy objectives. All subsequent project planning for HS2 can then trace back to this charter statement to ensure consistency with that vision.

Lifecycle usage: The project charter is produced right at the start of the project (initiation phase). In fact, developing the project charter is often the first process in PMI’s project management framework. Once approved, the charter formally kicks off the project and is the document that the project manager can brandish to say, “I have authority to proceed and commit resources.” During the project, the charter remains a point of reference for any high-level questions or disputes. It’s not usually updated (unlike the business case or project management plan, the charter is typically a fixed baseline unless the project undergoes a major pivot). The idea is that the charter captures the initial agreement and understanding about the project at the executive level. If anything in the charter needs to change (say the core objective or the fundamental scope), that likely means going back to the drawing board for re-approval – essentially a new charter.

Throughout the project lifecycle, the charter is a touchstone. At stage gates or project reviews, one might be asked: “Is the project still operating within the bounds of its charter? Have the objectives changed?” If the project starts experiencing scope creep, the charter provides the original scope definition to help reel it back in or formally approve a change. For the project manager and team, the charter is useful during planning as the guiding document – the detailed Project Management Plan (which we’ll discuss next) is essentially an expansion of the outline provided by the charter. Many organisations also use the charter in stakeholder communications: it’s a handy summary to share when explaining the project to new team members or external stakeholders to ensure everyone understands the high-level intent and strategic context.

To give a UK public sector example, a government IT project might have a charter endorsed by the Senior Responsible Owner (SRO) stating: “Project Phoenix will modernise the council’s finance system, in line with the council’s digital transformation strategy, enabling efficiency savings of £X and improved services to residents.” This charter would be referenced in kickoff meetings and perhaps included in induction packs for project staff. If halfway through the project someone suggests adding a HR system implementation to the scope, the charter’s clear focus on the finance system and its strategic justification helps the project manager (and sponsor) say no to that suggestion (or defer it), keeping the project aligned to its intended goals. In summary, the project charter might be short, but it has a long reach across the project lifecycle – from giving the initial green light with strategic alignment, to providing grounding and authority throughout execution and control.

Project Management Plan

What it is: Once the charter is in place, the detailed planning can happen – this results in the Project Management Plan (PMP). Think of the project management plan as the master blueprint for how the project will be executed and controlled. It’s not just a schedule or a Gantt chart (those are part of it); it’s the comprehensive document (or collection of documents) that covers everything from scope management, schedule, cost management, quality, risk, communications, resources, procurement, and so on. In formal terms, “a project management plan is a comprehensive document that outlines how a project will be executed, monitored, controlled, and closed”. It essentially translates the high-level intentions of the charter and business case into an actionable plan for the project team. The PMP typically includes the project’s baseline scope (often via a Work Breakdown Structure or requirements list), the schedule and milestones, the budget and funding info, quality standards, risk register and response plans, roles and responsibilities, stakeholder engagement strategies, and governance procedures (like how change requests will be handled). It might be a single consolidated document or a set of interrelated plans (e.g. a separate Risk Management Plan, Communication Plan, etc., all rolled up into the overall PMP).

Strategic alignment: The project management plan might seem very tactical compared to lofty strategy, but it is a crucial tool for maintaining alignment through the project’s life. How so? First, when creating the plan, the project manager and team will derive the project’s deliverables and activities from the project’s objectives (which, as we’ve discussed, come from the charter and business case strategic goals). This ensures that the work planned is precisely the work needed to achieve the strategic outcomes, and nothing extraneous. If the business case said the strategic goal was to improve customer satisfaction by 20%, the PMP will include, say, a deliverable like “Customer Service Training Programme” or “New Customer Feedback System” that clearly maps to that goal. By capturing these in the scope and ensuring the schedule and budget allocate resources to them, the PMP directly embeds strategic alignment into the project’s day-to-day plan.

Second, the project management plan sets the guardrails that keep the project on course to deliver the intended value. For example, it will define how changes are handled – typically via a change control process. This process will often include an assessment of any proposed change for its impact on scope, time, cost, and also on benefits or strategic objectives. A well-governed project will reject changes that don’t support the project’s objectives or risk diluting the benefits. In that sense, the PMP (through its change control, scope management, and risk management sections) acts as a protector of strategic alignment: it helps prevent the project from morphing into something that no longer serves the original purpose.

Finally, the project management plan is used to align stakeholders’ expectations and keep them focused on common goals. It’s a communication tool as much as a planning tool. As one source notes, the PMP “helps align stakeholders by clearly communicating the project’s objectives, deliverables, and timelines,” ensuring everyone works towards the same goals. This stakeholder alignment is critical for strategic alignment – if all key players understand how the project contributes to corporate strategy and what needs to be done to realise that, they are more likely to support decisions that uphold that strategy. For instance, in the Crossrail project, the overall project management plan (and subordinate plans for different sections and systems) would have been immense. But within those plans, the traceability from strategic requirements (e.g. increase rail capacity by 10% across London) down to technical requirements (e.g. number of trains per hour, station sizes) and then to work packages was maintained. This ensured that engineers and contractors were all delivering pieces that fit together to achieve the high-level benefit. If a contractor faced a decision like choosing between a cheaper material vs. a more durable one, they could refer to quality requirements in the PMP which in turn were derived from the strategic need for a reliable railway. That golden thread from strategy to execution is what the project management plan aims to preserve.

Lifecycle usage: The project management plan is primarily developed during the planning phase of the project, after the charter is approved. It usually goes through iterations and is reviewed by the sponsor or a governing body (like a Project Board in PRINCE2 or simply senior management in other frameworks) before being baselined. Once approved, it becomes the official game plan. During the execution phase, the PMP is the go-to reference for the project manager and team. They will use it to guide their work (for example, team members consult the schedule and work assignments, follow the defined processes for quality checks, update risks and issues log as per the risk management plan, etc.). The project manager uses it to monitor progress – for instance, comparing actual progress to the baseline schedule and cost defined in the plan – and control the project. If things deviate, the PMP provides the process for getting back on track (maybe through change requests or corrective actions).

As the project progresses, any significant changes will be documented through formal updates to the project management plan (with approvals). In effect, the PMP is a living document during the project; it may be refined with more detail or adjusted if changes are approved. However, all changes must keep the project aligned with its objectives – one doesn’t simply change the plan to something off-course, because as we noted, changes are evaluated for strategic impact. By the monitoring and controlling stages, the project management plan is the benchmark for performance. Reports on project status will reference the PMP baselines (e.g. “we are 2 weeks behind the plan’s schedule” or “spending is on track with the plan”). At project closure, the team will review how well the project stuck to the plan and met its objectives.

For example, consider a project management plan for a new London hospital construction project. The PMP will detail how to manage construction activities, procurement of medical equipment, stakeholder communications with hospital staff and local community, etc. All of these are tied into the higher goal (maybe the strategic goal is to increase healthcare capacity in East London). If during execution a contractor suggests a design change that could add more beds but delay opening by three months, the change control process kicks in – the decision makers would weigh this against the strategic objective of opening on time to serve the community need. Because the PMP had a hard deadline aligned with a broader NHS service rollout plan, they might reject the change to preserve that strategic timeline. Without a solid PMP, such decisions can become chaotic or purely cost-driven; with the PMP, there is a structured way to ensure that every major decision is made with the project’s strategic success in mind.

In summary, the project management plan is the engine room of the project – it doesn’t exist in isolation from strategy, but rather is the detailed map of how to get to the strategic destination promised by the charter and business case. A well-crafted PMP keeps the project’s daily work aligned with the strategic outcomes by providing clarity, consistency, and control mechanisms throughout the project lifecycle.

Project Success Measures

What they are: How do we know if our project has been successful? This is where project success measures come in – sometimes called success criteria or key performance indicators. These are the specific measurable indicators that tell us whether the project met its objectives. Success measures can be both project-focused (often the classic “triple constraint” of delivering on time, within budget, and to scope/quality) and product- or outcome-focused (achieving the intended benefits and stakeholder satisfaction). APM defines project success in terms of stakeholder satisfaction and meeting the agreed success criteria at the start of the project. In practice, success measures are agreed early on with key stakeholders (sponsor, customer, end-users) and documented – possibly in the business case or charter, or in a separate success criteria section of the project management plan. They answer the question: what will success look like? For example, success measures for a project to launch a new smartphone might include: Time – launch by Christmas shopping season; Cost – within £10m budget; Quality/Scope – phone passes all regulatory tests and includes features A, B, C; Benefit – achieve 100,000 units sold in first quarter; Stakeholder satisfaction – positive feedback from at least 80% of test users. These criteria give everyone a clear target to aim for.

Strategic alignment: It’s important that the project’s success measures reflect not just the internal project management goals (like hitting deadline and budget) but also the achievement of strategic outcomes. After all, a project could be delivered on time and on budget and still be a failure if it doesn’t deliver value or advance the strategy. That’s why defining success measures is tightly linked with the earlier documents: the business case and benefits plan define the expected strategic benefits, and those should feed into the success criteria. For instance, if the strategy-driven business case for a new railway line (e.g. Crossrail) was about reducing commute times and boosting economic development, then a key success measure might be “average commute time reduction of X minutes for 80% of riders” or “£Y million of economic growth in outer London boroughs within 5 years.” These directly tie the notion of success to the strategic objectives. By contrast, narrower project management metrics (like completing construction by a certain date or within budget) are important to the management of the project, but true success in the strategic sense also requires those promised benefits to come through.

In the context of PMP and APM exams, it’s often highlighted that project success criteria should be agreed with stakeholders and encompass more than the triple constraint – including things like meeting the functional purpose of the project and realising benefits. An aligned set of success measures ensures that when the project is declared “successful,” it inherently means the organisation’s strategic needs were met. Conversely, if a project meets all internal delivery targets but fails to deliver benefits, the success measures (if properly defined) would reflect that as a shortfall. For example, the success of an NHS project implementing a new patient portal wouldn’t be judged solely by “was it delivered by March for £2m?” but also by “is patient appointment booking now easier and faster, contributing to the NHS’s strategic goal of digital access?” – measured perhaps by a 50% reduction in phone bookings or a patient satisfaction score improvement. By defining that metric up front as a success measure, the project team is reminded throughout that technical delivery alone isn’t enough; it has to achieve the strategic outcome to truly succeed.

Lifecycle usage: Success measures (or criteria) are ideally established at the initiation/planning stage. They might first appear in the business case and be firmed up in the project charter (the charter often lists high-level success criteria). During detailed planning, the team may refine these measures and ensure they are SMART (Specific, Measurable, Achievable, Relevant, Time-bound). Throughout the project, these measures then act as a guiding light. Project status reports may include progress toward certain success targets (for instance, during a pilot rollout, you might track interim user satisfaction scores). However, some success measures can only be fully evaluated at project closure or beyond. A common approach is to distinguish between project delivery success (did we do what we said we’d do, when and for how much?) and project outcome success (did it deliver the value we wanted?). At project closure, the project manager will often produce a closure report or final report evaluating success against the criteria set out initially. For any criteria not achieved by closure (e.g. long-term benefits), the responsibility might be handed to operations or a benefits realisation team to follow up post-project.

During execution, if decisions or changes are proposed, the success criteria provide a reference to evaluate impacts. For example, if cutting a certain feature might jeopardise a success criterion related to user satisfaction, the team can flag that and the sponsor can weigh the trade-off. In risk management, risks to meeting success criteria are identified and mitigated. Say one success measure is a 15% cost reduction in a process; a risk might be that staff don’t adopt the new process (mitigation could be extra training – this would go into the plan). Thus, success measures are weaved into project controls.

To illustrate, let’s revisit HS2. Some success measures for HS2 Phase One could be: Capacity increase – e.g. 5,000 additional seats per hour on the rail corridor; Travel time reduction – London to Birmingham in 49 minutes (down from 1h 21m); Economic benefit – £X billion added GVA in the Midlands within 10 years; Environmental target – net-zero construction by 2035 (as per strategic goals). These would have been set based on strategic cases and government objectives. During the project, progress can be partially gauged (e.g. are we on track with environmental measures? how is the construction footprint looking?), but the true test comes when the railway is operational. The project’s closure (for construction) will hand over data and plans for the operational team to measure these outcomes. The fact that these measures were defined from the start means HS2’s entire development was geared toward meeting them: engineering specifications, for example, were driven by the journey time targets and capacity figures. In this way, clearly defined success measures from the outset help to engineer the project for strategic success.

In summary, project success measures ensure that “success” is not an ambiguous term or just internally focused. By defining and using these criteria throughout the project, especially ones that tie to strategic objectives, the project team and stakeholders maintain alignment on what they’re collectively trying to achieve. It provides accountability (at project end, you have a clear yardstick) and keeps everyone honest – no declaring victory unless those strategic goals are hit. For apprentices in project control, always remember: define success early, keep it visible, and let it guide your decisions.

Organisational Goals and Strategy

Before any project is conceived, there are the organisational goals and strategy that form the backdrop. This is essentially the strategic plan of the organisation – its vision, mission, and high-level objectives (perhaps laid out in a strategy document or business plan). These goals might be, for example, a government department’s strategy to achieve net-zero emissions by 2050, or a retailer’s goal to expand into online markets and increase market share by 10%. Projects are born from these strategic aims. In a structured organisation, the portfolio of projects is selected and prioritised based on how well each potential project contributes to the strategic objectives. In other words, organisational strategy is the why behind the why: it drives the creation of business cases (each business case must show which strategic goal the project supports), and it guides sponsors and portfolios in approving the right projects. As one PMI article noted, “by aligning projects with strategy, organizations can ensure that they invest only in those initiatives which enable them to accomplish their objectives.”. This means that ideally, there is a direct line of sight from the highest-level strategic goals down to each project’s goals.

Top-down alignment: Organisational strategy provides direction and constraints for projects. For example, if a company’s strategy is to become a leader in sustainable products, it might set a goal that all new projects must have a demonstrable environmental benefit. This would trickle down into business case requirements (no project gets funding unless it supports the sustainability goal) and even into how project success is defined (maybe including a carbon reduction metric). Many organisations use portfolio management processes to evaluate project proposals against strategic criteria – ensuring strategic alignment at the approval stage. The APM glossary describes the “host organisation” (the investing organisation) as the one providing strategic direction and expecting to reap benefits, which underscores that projects are a means to an end (the end being strategic objectives).

Bottom-up contribution: Once projects are underway, their outcomes should cumulatively advance the organisation’s strategy. If strategy is the ship’s compass, projects are the engine moving it forward in specific directions. There’s usually a hierarchy: portfolios and programmes are collections of projects all contributing to broad strategic themes. For instance, the UK Government’s strategy on improving national infrastructure is executed via programmes like HS2, Crossrail, new highways, etc., each with multiple projects. Each project initiation document we discussed (business case, charter, etc.) often has a section explicitly referencing the strategic goal. For example, a local council’s project charter might quote from the council’s corporate plan: “This project supports Priority 2 of our Corporate Plan: ‘A greener borough’, by delivering energy-efficient street lighting.” This makes it crystal clear how the project plugs into the bigger picture.

Maintaining alignment: Organisational strategy isn’t static; it can evolve due to internal or external changes (new competitors, policy changes, economic shifts). Thus, a project initiated under one strategy may need to be checked against any strategy updates. In practice, this is another reason business cases are revisited – to ensure the project is still aligned with the current organisational strategy. If a drastic strategy shift occurs (say, a company decides to exit a certain market), projects related to that market might be re-scoped or cancelled. Effective governance involves periodically scanning the strategic horizon and confirming that each project is still relevant. Conversely, projects themselves can sometimes inform strategy – a successful project might reveal new opportunities that shape future strategy. For example, the NHS COVID-19 vaccine rollout project was not in any long-term plan (it arose from crisis), but its success and methods (like mass vaccination centres) could influence the NHS’s future strategy for large-scale public health interventions.

From a learning perspective, as a project professional you should always be aware of your organisation’s or client’s strategic objectives. When you read a project initiation document, you should be able to trace any high-level requirement or benefit up to a strategic goal. If you can’t, that’s a warning sign of a potential misalignment. This is why exam questions in PMP or APM might ask about how to ensure strategic alignment – typical answers involve referencing the business case, engaging the sponsor (since the sponsor is the link to strategy), and using benefits management to keep focus on strategic outcomes.

To give a concrete UK example of strategic alignment: The NHS Long Term Plan sets goals like improving cancer survival rates and digital access to services. In alignment, we see projects like building new proton beam therapy centres (to advance the cancer care goal) or developing the NHS App (to advance digital access). Each of these projects, in their charters and business cases, explicitly mentions the NHS strategic aim they contribute to. The benefits (e.g. number of cancer patients treated with advanced therapy, or percentage of appointments booked online) tie back to metrics the NHS cares about at the strategic level. Thus, when those projects deliver, their success can be measured in terms the organisational leadership understands and values.

In summary, organisational goals and strategy are the source and sink of project alignment: they generate the demand for projects (source), and they are the destination where project benefits should eventually appear (sink). All the project initiation documents we’ve discussed are, in one way or another, mechanisms to connect the project to this strategic anchor. If the strategy is the “north star,” these documents are the compass and map that ensure the project sets off in the right direction and continues to navigate by that star.

Summary Comparison Table

Finally, let’s compare each key document/concept we’ve covered – by their main purpose, who owns them, when they are created/used, and how they specifically help align the project with strategic goals:

Conclusion

Strategic alignment is not a one-time task at project initiation; it is a golden thread running through the entire project lifecycle. From the moment a project is conceived, through planning and execution, and even into post-closure benefits realisation, the documents we’ve discussed work together to keep the project on strategy. A well-crafted business case convinces everyone that the project is worth doing for strategic reasons. A benefits management plan keeps eyes on the prize, ensuring those strategic benefits are delivered. The project charter gives the official nod, embedding the strategic purpose into the project’s DNA from day one. The project management plan then charts a careful course to achieve that purpose, while robust success measures define what victory looks like in strategic terms. All of this happens under the umbrella of organisational goals and strategy – the guiding star that projects must follow to deliver real value.

For a Project Controls Professional (and indeed for any project manager or sponsor), understanding and utilising these documents is crucial. They are not just paperwork or bureaucratic hurdles for exams; they are practical tools that, when used properly, make the difference between projects that tick boxes and projects that genuinely drive an organisation forward. By approaching your projects with strategic alignment in mind – and using these documents to communicate and enforce that alignment – you’ll be well equipped to deliver projects that not only meet their requirements but also make a meaningful impact on your organisation’s goals. This is the mindset that professional bodies like PMI and APM seek to instil, and it’s the hallmark of project professionals who achieve consistent success in the field. Keep this guide handy as you prepare for your PMP, APM PQ, or Chartered assessments, and importantly, as you embark on real-world projects – because aligning what we do with why we do it is at the heart of professional project management.

see attached

Assignment: Applying Lean Project Management Principles (Optional Assignment) 

Task Overview:
After reading the section on Lean Project Management, complete the following activities to reinforce your understanding, apply the principles practically, and document your learning and improvements effectively.

Activities:

1. Summarise the Section
   Provide a clear and concise summary of the Lean Project Management section. Focus on key points, core principles (value, value stream, flow, pull, perfection), and essential tools such as Value Stream Mapping and Kanban.

2. Create a Mind Map
   Develop a visual mind map that highlights key concepts, principles, examples, and techniques learned from the Lean Project Management topic. Ensure clarity, visual appeal, and completeness.

3. Identify Relevant KSBs
   Reflect on the Knowledge, Skills, and Behaviours (KSBs) covered in this section. Specifically, consider:

   • K1: Management (leadership, governance, efficiency, waste reduction, continuous improvement)

   • K4: Time Management

   • K22: Continuous Improvement Techniques

   • S1: Management Procedures and Continuous Improvement

   • S2: Data Analysis

   • S4: Time Management and Scheduling

   • K27: Data Analysis and Assurance

   • B4: Teamwork and Collaboration

   • B5: Innovation and Continuous Improvement

   Clearly outline how you believe these KSBs can be enhanced through learning and applying Lean principles.

4. Practical Application and Team Discussion

   • Arrange a meeting with your project team to discuss Lean principles.

   • Conduct a brainstorming session to identify ways to make your current projects leaner by removing waste and increasing efficiency.

   • Document your current project performance metrics clearly. Include specific examples (e.g., lead time, cycle time, delays, waste areas).

   • Agree as a team on actions for improvement, applying Lean tools such as Kanban or Value Stream Mapping.

5. Document Improvement and Reflection
   After applying these Lean improvements, track and document any changes in efficiency, effectiveness, or quality in your project.

Submission and Reporting:

• Upload your summary, mind map, KSB analysis, and reflection on practical application to APTEM under the LMS section.

• Clearly label your activities and reflect specifically on your learning journey and team discussions.

• Log 2 to 4 hours for this assignment, ensuring your submission is detailed and reflective of the time committed.

Completing this assignment will consolidate your understanding, enable practical application of Lean Project Management principles, and help you measure and enhance project performance effectively.

Apprentice Assignment: Applying Value Stream Mapping (VSM) in Your Project

Assignment Objective:

You will apply the principles of Value Stream Mapping (VSM) to a process within your workplace. This assignment aims to help you identify and reduce waste, enhance efficiency, and improve overall project delivery.

Task Instructions:

Step 1: Choose a Process

Select a clearly defined process from your current workplace project. Examples include:

• Manufacturing line processes

• Software development workflows

• Patient journeys in healthcare

• Construction project phases

Step 2: Create a Current State Value Stream Map

• Clearly document each step of the current process.

• Identify and note value-added and non-value-added steps.

• Record key metrics such as cycle times, wait times, bottlenecks, inventory, or backlog.

Step 3: Analyse the Current State Map

• Identify waste and inefficiencies (delays, unnecessary movement, excessive inventory, waiting times).

• Clearly document these findings.

Step 4: Design a Future State Value Stream Map

• Suggest improvements to eliminate waste and streamline the process.

• Illustrate how these changes will improve the flow of value.

• Provide estimated improvements in cycle time, efficiency, or resource utilisation.

Step 5: Prepare an Implementation Plan

• Outline the steps necessary to move from the current state to the future state.

• Include roles, responsibilities, and timelines.

Step 6: Reflect and Report

• Write a short reflective summary detailing your learnings from applying VSM.

• Discuss how this technique improved your understanding of project efficiency.

• Suggest how VSM could support ongoing improvements in your project.

Submission Guidelines:

• Submit your Value Stream Maps (Current and Future State).

• Include your implementation plan and reflective summary.

• Upload all documents clearly labelled to your APTEM portfolio.

KSB Mapping:

By completing this assignment, you will address the following Knowledge, Skills, and Behaviours:

Knowledge:

• K3: Technical Procedures and Methods (applying structured process improvement methods)

• K23: Data Management and Analysis (using process data to identify areas for improvement)

• K25: Risk, Commercial, and Financial Controls (evaluating efficiency and cost implications)

Skills:

• S2: Data (collecting and interpreting process data to enhance project delivery)

• S4: Time (identifying and addressing inefficiencies and delays)

• S6: Risk (analysing risks associated with inefficiencies and proposing mitigations)

Behaviours:

• B4: Teamwork and Collaboration (engaging colleagues in mapping and implementing improvements)

• B5: Innovation and Continuous Improvement (demonstrating proactive improvement initiatives and creative problem-solving)

Estimated Completion Time:

• Total: 6–8 hours (including mapping, analysis, implementation planning, and reflection)

Complete this assignment thoughtfully and use it as an opportunity to significantly enhance your project’s effectiveness and your professional skills.

This is what you need for PMP exam 

Please note: It may be too overwhelming to complete all three assignments. You only need to choose one of the three topics. There’s no need to study each in detail—simply review the three briefly, and focus on this section, which highlights the key points most relevant to the PMP exam.

Welcome to the ultimate guide to mastering Microsoft Project! In this video, I introduce you to our comprehensive series: MS Project The Course, a 25-video collection designed to take you from beginner to expert in project management using MS Project. Each video in this series includes free downloadable files that allow you to follow along step-by-step while learning MS Project. These resources are designed to help you practice as you learn, making your journey to project management mastery both interactive and effective.

Whether you're new to MS Project or looking to sharpen your skills, this series offers step-by-step guidance, real-world tips, and practical checklists to boost your project management efficiency.

please see attached

see attached

Workbook: Exercises for Practicing User Story Concepts

To solidify your understanding of user stories and their application, here are some workbook-style exercises. These exercises are designed for you to apply the concepts in professional or project scenarios relevant to you. They can be done individually or in study groups. Remember to think in terms of Agile and PMP principles as you work through them.

1. Identify Users and Write User Stories
Think of a project (past, present, or an imagined one) in your domain. Identify at least two distinct user personas or roles who have requirements from that project. For each persona, write 2-3 user stories that capture something that user needs from the project deliverable. Use the "As a ..., I want ..., so that ..." format.
For example: If you work in marketing and the project is launching a new website, one persona could be a visitor to the site: “As a site visitor, I want to filter the product catalog by category so that I can find products relevant to my interests quickly.” Another persona might be an admin: “As a content manager, I want to schedule blog posts in advance so that the site updates can happen on weekends without my manual intervention.”
After writing the stories, check: do they clearly convey who, what, and why? Would they be understandable to both a business stakeholder and a technical team member? If possible, share with a colleague to see if the value is clear.

2. Apply the INVEST Criteria
Take the user stories you wrote in Exercise 1 (or you can use the examples provided). Evaluate each story against the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable). For each criterion, ask:

• Is the story independent of others, or is it entangled with another? If entangled, how could you restructure it?

• Is the wording of the story negotiable, or does it prematurely specify a solution? If it’s too rigid (e.g., it says “implement X using Y technology”), rewrite it to be more open.

• Is the story clearly delivering value? Identify the benefit; if it’s not obvious, maybe the “so that” needs improvement.

• Is the story estimable? What unknowns might prevent estimation? (For instance, “I want the system to be intuitive” – not estimable because it’s vague. How to fix? Make it concrete or split it.)

• Is the story small enough? Could it be done in a few days? If it seems too large, practice story splitting: break it into smaller stories. Common ways to split include by workflow steps, business rules, happy path vs. edge cases, data types, etc. Write down the new smaller stories if any.

• Is the story testable? Try to imagine at least one acceptance test for it. If you struggle (e.g., “intuitive system” has no test), refine the story until it’s testable (perhaps redefine “intuitive” into specific criteria like “user can complete key task in <2 minutes without help”).
  For each story, jot down notes on any criteria it fails and how you addressed it. This will train you to critique and improve user stories, a valuable skill both for Agile projects and for PMP exam scenarios.

3. Draft Acceptance Criteria
Using one of your user stories (preferably one that’s now INVEST-worthy), write a set of acceptance criteria for it. Aim for 3-5 criteria that cover the main conditions of satisfaction. Use bullet points or given/when/then format. The criteria should cover normal success conditions and maybe one negative case (if applicable).
Example scenario: For the story “As a customer, I want to track my package so that I know when it will arrive,” acceptance criteria might include:

• “Given a valid tracking number, when I enter it, then I see the current status and expected delivery date of my package.”

• “If I enter an invalid tracking number, I receive an error message instructing me to check the number.”

• “The tracking status updates at least every 6 hours (so information is reasonably current).”
  Now it’s your turn: pick a story relevant to your project and write criteria. Afterward, ask yourself: Are these criteria testable and unambiguous? If you gave them to a tester or a developer, would they understand exactly what to build/check? Refine as necessary. This exercise helps you practice specifying requirements in a clear, testable manner, which is valuable for both Agile and traditional projects.

4. Prioritise a Backlog of User Stories
Imagine you have a list of 8 user stories for a new feature rollout (they can be from exercises above or a new set you dream up). Assume due to time constraints, you can only implement 5 of them in the next release. Prioritise the stories using one of the techniques discussed:

• Try using MoSCoW: Label each story as Must, Should, Could, or Won’t for the upcoming release. Explain briefly why you assigned each label (e.g., “Story A is Must because without it the product won’t function for its main use case,” “Story B is Could – nice enhancement but not critical”). After categorising, decide which ones make the cut (all Musts and maybe some Shoulds until you fill 5 slots).

• Alternatively, use a Value vs Effort matrix: Assign a relative business value (e.g., 1 to 10) to each story and an effort estimate (say in points or t-shirt sizes S/M/L). Plot them conceptually or just list High/Low categories. Choose the 5 that give highest value for least effort (quick wins and important ones).
  List out your ordered backlog from 1 (highest priority) to 8 (lowest). Compare the outcome of your prioritisation exercise to what your intuition might have chosen without a method – did the structured approach make you reconsider any story’s importance? This exercise teaches prioritisation thinking, aligning with the PMP concept of delivering the highest value features first and being able to justify the rationale.

5. From User Story to Task (Bonus exercise)
This exercise blends into project execution planning. Take a user story (perhaps one you already wrote criteria for in Exercise 3). Break it down into sub-tasks or activities that a developer or team member would need to do to implement it. This is akin to going from a story (deliverable) to a mini work breakdown. For example, for “add credit card to wallet” story, tasks might be: design input form UI, implement frontend validation, implement backend API call to card processor, implement token storage in database, write unit tests, etc. Why do this? It helps see how user stories relate to traditional WBS tasks – the story is like a work package, and these are the activities under it. It also prepares you for questions where you might need to connect agile artifacts to project planning (i.e., in agile, detailed planning is often done at the task level during sprint planning, not up front).
After listing tasks, consider: these tasks would typically all be done within one iteration for that story, by the cross-functional team. There’s no need to treat them as separate deliverables – they are just a means to get the story “Done”. This reinforces the idea that completion is measured at the story level (the user-visible functionality), not task level.

By working through these exercises, you’ll deepen your grasp of how user stories function as a tool for requirements, planning, and stakeholder engagement in Agile projects. You’ll also see how these map to the project management processes you know. Remember, practice in crafting user stories and thinking in an Agile mindset will not only help in exam questions (particularly scenario-based ones where you must choose the agile-friendly approach) but also in real project situations as Agile practices become more prevalent in various industries. Good luck, and enjoy “storytelling” in your project management journey!

see attached

Workbook Exercise: Creating Your Impact Map 

Apprentices are encouraged to apply these steps through a structured workbook exercise:

Exercise Instructions:

1. Select a real project from your professional environment.

2. Clearly state the goal of your project.

3. Identify key actors (at least three).

4. Determine the impacts required from each actor.

5. Define specific deliverables that lead to these impacts.

Example Workbook Structure:

• Goal:

• Actors and Their Roles:

  • Actor 1:

    • Impact:

    • Deliverables:

  • Actor 2:

    • Impact:

    • Deliverables:

  • Actor 3:

    • Impact:

    • Deliverables:

• Reflection:

  • How does your map enhance clarity?

  • What challenges do you anticipate in achieving these impacts?

Apprentices should complete this exercise individually and then collaboratively review in peer groups to enhance understanding and refine their impact maps.

please see attached

please see attached

please see attached

Workbook Activities for Apprentices:

Activity 1: Practical MVP Exercise

Task: Choose a current or hypothetical project. Identify an MVP version of your product/service.
Activity: Clearly list essential functionalities and features, focusing strictly on core value.
Outcome: Outline an MVP concept document, including justification for your choices.

Activity 2: Designing MMF

Task: Select an additional feature for your chosen project to create a marketable advantage.
Activity: Describe why your chosen feature can independently attract customers or generate revenue.
Outcome: A brief marketing pitch focusing on your chosen MMF.

Activity 3: MEA Planning

Task: Identify a minimal economic activity that could validate your project's economic feasibility.
Activity: Develop a simple test scenario to verify market demand or profitability.
Outcome: Write a summary of your MEA plan with clear economic criteria.

Activity 4: MRF Technical Exercise

Task: Identify the smallest technically deployable feature set from your current project backlog.
Activity: Describe the feature, focusing on its readiness and impact on continuous delivery.
Outcome: Brief deployment strategy documentation for your MRF.

please see attached

The video explores: 

• The difference between achieving product–market fit and building a scalable company, highlighting the importance of early thinking around pricing, go-to-market, and business models.

• The “product-to-company gap” and why many products succeed technically but fail to scale commercially.

• Real-world examples showing that product success must be supported by effective monetisation and distribution.

• The role of MVP, minimum viable segment, value proposition, and pricing in designing for scale.

• The need to build products that are simple, easy to adopt, and designed for repeatable growth, not just initial success.

This video explores:

Why defining a compelling value proposition is critical to avoid building products people don’t really need.

How to understand and evaluate customer needs, distinguishing between solving minor versus major problems.

The importance of identifying your target audience and specific use cases.

Frameworks for developing value propositions that move a product from “nice-to-have” to “must-have”.

Common pitfalls like focusing on features rather than solving core customer needs and relying on vague superiority claims (“faster/better/cheaper”).

Apprentice Exercise: Backlog Refinement in Practice

Objective: Apply backlog preparation and refinement techniques in a simulated professional scenario. This exercise is designed for apprentices to practice creating and grooming a product backlog, using templates and collaborative discussion, just as they would in a real agile project.

Scenario: You are part of a project team developing a new e-commerce website for a retail client. The project is being run using Agile (Scrum). The high-level goal is to create a functioning online store with user registration, product catalog, shopping cart, and checkout/payment capabilities. The product owner has provided some initial ideas and requirements, but it’s up to the team to flesh these out and maintain the backlog.

Part 1 – Backlog Preparation:

1. Create an Initial Product Backlog: Start by drafting a Product Vision Statement (one or two sentences that describe the aim of the product). Then, create a product roadmap outlining 4-5 key features or epics (e.g., User Account Management, Product Browsing, Shopping Cart, Checkout & Payment, Order Tracking). Use this as a framework to populate an initial backlog. For each epic, brainstorm user stories that would fall under it. Write the user stories on index cards or sticky notes (physical or a digital tool like Trello/Jira), using the user story template. For example: under “Checkout & Payment” epic, you might create stories like “As a shopper, I want to save my shipping address for future use” or “As a shopper, I want to receive an email confirmation after purchase”. Aim to create 15-20 user stories in total across all epics for this initial backlog draft.

2. Use a Backlog Template: To organize, fill out a simple backlog spreadsheet or table with columns for Story ID, User Story Description, Priority, Estimate (Story Points), and Notes/Acceptance Criteria. You can use a template (for instance, an Excel or Google Sheets backlog template, or a Jira backlog if available). Initially, assign a rough priority (High, Medium, Low) to each story based on your understanding of the client’s needs (e.g., core purchase functionality would be High, nice-to-have wishlist feature might be Low). Don’t worry about estimates yet; just get the structure in place.

3. Discuss with Stakeholders: Since backlog creation is iterative, imagine presenting this initial backlog to the product owner or client for feedback. What questions might you ask to validate priorities? (e.g., “Is offering coupons more important than enabling product reviews at launch?”) Note down any new requirements they mention or any changes in priority. This simulates stakeholder engagement in backlog preparation.

4. Progressive Detailing: Recognize that not all stories need full detail now. However, pick two high-priority user stories (perhaps one from “User Account” and one from “Checkout”) and flesh them out as if they were to be done in the first sprint. Write down acceptance criteria for these stories (e.g., for “user receives email confirmation”: criteria could be “Email is sent to user’s registered address after payment is successful with order details; If payment fails, no confirmation email is sent; Email format matches company branding”). This practices how to go from a one-line story to a more detailed requirement when needed.

Outcome of Part 1: You should have an initial product backlog document with a list of user stories, each with a basic description and priority. You will have also practiced writing detailed acceptance criteria for a couple of items. This simulates the backlog preparation phase, turning a project vision into a set of story tickets ready for refinement.

Part 2 – Backlog Refinement (Iteration):
Now assume the project is underway. It’s the middle of Sprint 1, and it’s time to do backlog refinement for future work.

5. Refine and Estimate: Take the backlog you created and conduct a mock backlog refinement meeting. You can do this as a group exercise with fellow apprentices or team members, or individually by simulating multiple perspectives:

   • Go through the top 5-7 stories in your backlog (the ones marked High priority). For each, discuss “Do we all understand this story? Is it still relevant and highest value? What questions do we have to answer before implementing it?” If any story seems too large or vague, practice splitting it. For example, if you have a story “As a customer, I want to search for products so I can find items quickly,” you might split it into “search by product name” vs “filter by category” if it’s too big to do at once.

   • Next, assign estimates. Use Planning Poker technique: even if doing it solo, you can decide on a story point number (e.g., 1, 3, 5, 8…) for each refined story. If working in a group, each person can “play” a number card simultaneously, then discuss differences. The goal is to reach consensus on an estimate. This will likely require discussing the implementation approach briefly, revealing if more details are needed. Document the agreed estimate in the backlog table.

   • Ensure each of these top stories has at least a few acceptance criteria or notes. If any dependencies or questions are identified (e.g., “Need to clarify with payment gateway vendor”), note those too.

6. Apply Prioritization Changes: Imagine that since backlog creation, some changes occurred. For example, say the client reported that many users abandon the cart at payment – indicating Checkout improvements are urgent. Also, a competitor just launched a discount coupon feature that the client wants to match. Reflect these by adding or reprioritizing items:

   • Add a new story like “As a shopper, I want to enter a promo/coupon code at checkout to get a discount” (probably High priority now).

   • Mark an existing story about “improving checkout UX” as High if it was lower.

   • Perhaps downgrade another feature (e.g., “user profile avatar upload”) to lower priority for now.
     After reprioritization, explicitly reorder the backlog list. In your spreadsheet or tool, make sure the items are sorted by priority (or add a rank number). Now the backlog should reflect the latest priorities.

7. Practice the “DEEP” Check: Review your refined stories against a Definition of Ready or the DEEP criteria:

   • Detailed Appropriately: Are the top stories detailed enough (clear to the team)? If not, add detail.

   • Estimated: Did you estimate them? (Yes, in step 5).

   • Emergent: Is your backlog updated with the new story and priority changes? (Yes, in step 6, showing it’s evolving).

   • Prioritized: Do you have a clear ordering of items by importance? (Ensure this after step 6).
     If any criterion is not met, take action to fix it (e.g., if a story is still unclear, flesh it out more or leave a question for the product owner).

8. Simulate Sprint Planning Pick: As a final part of refinement, pretend you are at the sprint planning for Sprint 2. From your now-refined backlog, select a set of stories that would fit into the next sprint (given the estimates and your team’s velocity – e.g., assume your team can do ~20 points a sprint). Make sure you only select stories that meet your “ready” criteria. This will validate whether your refinement was sufficient. If you struggle to find enough ready stories, that indicates where refinement needs to improve.

9. Reflection: Reflect on the process by discussing or writing answers:

   • How did prioritization change after getting new information (and how did that feel versus a static plan)?

   • Were there any surprises during estimation (stories larger or smaller than thought)?

   • How does splitting a story help in making it more manageable?

   • If working with others: how did the team arrive at consensus during refinement? What conflicts or differing opinions arose, and how were they resolved?

   • What would you do before the next refinement meeting to improve (e.g., have the product owner clarify certain stories offline, research a technical solution for an upcoming story, etc.)?

This exercise gives hands-on experience with backlog grooming. By preparing an initial backlog and then iteratively refining it, you mimic the cycle of an agile project – capturing requirements and continuously revisiting them. In a real professional setting, backlog refinement would be ongoing throughout the project, and this practice helps build the skills to manage that.

Tips: If possible, use actual tools like a Jira free trial or a Trello board for this exercise to familiarize yourself with backlog tooling. Many such tools have backlog templates (Atlassian offers a free product backlog template) which can save time. Also consider pair-working with a colleague where one plays “Product Owner” and one plays “Scrum Master/Dev Team” to simulate conversation in refinement. This will improve your communication and negotiation skills around scope.

Story Points are one of the most misunderstood and misused terms with Agile teams. In this video I explain what a Story Point is, Story Points vs hours estimation and how they are different, and how Story Points are used in Jira.

This is the second video in our series on Relative Estimation. In this video I cover:

• What is Planning Poker
• How a Planning Poker session is run
• When to perform Planning Poker
• The benefits of this approach

This is the third video in our series on Relative Estimation. In this video I cover:

• What is Velocity?
• How Velocity can be used to determine a long-term forcast
• How to use Jira to calculate Velocity?
• Tips when it comes to using Velocity

This is the fourth video in our series on Relative Estimation. In this video I cover:

• How to create a release in Jira
• Assigning work to a release
• Adding relevant information
• Creating time-based vs scope-based release plans