Once you have finished reading this chapter, please log your completion on APTEM. The suggested time for this activity is 3 hours.
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:
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.
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.
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.
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.
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.
Assignment: Implementing Kanban in Your Workplace (Optional Assignement)
Objective: Apply Kanban principles and methods to improve workflow management in your current workplace or a specific project you are involved with.
Instructions:
Assess Current Workflow:
Clearly identify and document the current workflow process within your workplace or project area. This can be any process you engage with regularly, such as task management, customer support, product development, or administrative processes.
Create a Kanban Board:
Set up a physical or digital Kanban board to visualise the stages of your identified workflow.
Clearly label the columns (e.g., "To Do", "In Progress", "Review", "Done").
Define Work Items:
Identify tasks or activities as "work items" and place them appropriately on your Kanban board.
Set Work-in-Progress (WIP) Limits:
Determine and implement suitable WIP limits for each column to control task overload and promote efficient workflow.
Implement and Monitor:
Run your Kanban board for a minimum of two weeks, ensuring regular updates.
Monitor how effectively the WIP limits manage flow and identify any bottlenecks.
Analyse and Reflect:
After two weeks, review the effectiveness of your Kanban implementation.
Document any improvements in workflow, such as reduced task completion time, better visibility of workload, or enhanced team collaboration.
Reflect on challenges you encountered and propose adjustments or improvements for continued use.
Submission to APTEM:
Upload a detailed report including:
Initial workflow description
Screenshot or photograph of your Kanban board
Reflection on the implementation process and outcomes
Suggested future improvements
Time Allocation: You can allocate and report 2-4 hours in APTEM for completing this assignment.
Here are some excellent YouTube videos to support users completing the Kanban assignment:
A clear and concise introduction to the essential principles of Kanban—ideal for apprentices getting started.
An accessible walkthrough of setting up a board, including WIP limits and swimlanes—great for practical implementation.
Here are some high-quality YouTube videos from the UK and US that provide practical guidance for apprentices setting up a Kanban system:
A thorough walkthrough of setting up a Kanban board, explaining the essential elements—columns, cards, WIP limits—using clear, professional instruction.
Perfect for newcomers, this guide explains why Kanban is effective, how to launch a board, and offers hands-on tips to get started.
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.
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
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.
Identify waste and inefficiencies (delays, unnecessary movement, excessive inventory, waiting times).
Clearly document these findings.
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.
Outline the steps necessary to move from the current state to the future state.
Include roles, responsibilities, and timelines.
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.
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.
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)
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.
Welcome to this essential chapter on Agile Project Management, focusing specifically on three powerful methods: Lean, Kanban, and Value Stream Mapping. These techniques provide invaluable tools to manage projects effectively, enhance team collaboration, and drive continuous improvement—key elements of successful project management practices.
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 the final section, which highlights the key points most relevant to the PMP exam.
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.
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!
Apprentices are encouraged to apply these steps through a structured workbook exercise:
Exercise Instructions:
Select a real project from your professional environment.
Clearly state the goal of your project.
Identify key actors (at least three).
Determine the impacts required from each actor.
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.
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:
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.
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.
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.
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.
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.
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.
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).
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.
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.
To solidify your understanding, the following assignment will allow you to apply one or more of the methodologies (FDD, AUP/RUP, or MVP concepts) to a real situation in your workplace. This will demonstrate your ability to translate theory into practice – a key expectation at Level 6.
Assignment Title: “Agile in Action” – Implementing Iterative Approaches in a Live Project
Objective: Identify an opportunity in your current project or organization where an agile or iterative approach could improve outcomes, and carry out a mini-project or pilot using that methodology. Document and reflect on the process and results.
Tasks:
Select a Project or Workstream: Choose an ongoing project (or a significant workstream within a project) in your workplace that could benefit from an agile/iterative approach. Ideally, pick something with manageable scope for this exercise – for example, a component of a larger project, a new reporting system you need to develop, a process improvement initiative, or a small software/tool development if applicable. Make sure you have the support of your manager or mentor to experiment with a new approach in this area.
Choose a Methodology to Apply: Decide which methodology or concept from this module fits best. Options could include:
Feature-Driven Development (FDD): If your work involves delivering a set of functionalities or outputs, you might apply FDD by breaking the work into a feature list and executing a “design by feature, build by feature” cycle for a couple of those features.
Agile Unified Process (AUP) or Rational Unified Process (RUP) principles: If your project has defined phases or stage gates but lacks agility, try injecting an iterative cycle within a phase. For instance, during a planning phase, perform two short iterations of planning & prototyping rather than one long pass. Or use RUP’s risk-driven approach by identifying a high-risk element and running a mini Elaboration on it now.
Minimum Viable Product (MVP): If you are developing a new product, service, or internal process, define an MVP for it. Alternatively, use an MVP mindset to pilot a new solution on a small scale (e.g., test a new reporting process with one department before rolling out company-wide).
Choose the approach that aligns with your scenario – you might even combine ideas (e.g., use FDD’s feature breakdown and treat the first feature delivered as an MVP to gather feedback). Clearly state your choice and rationale in your assignment write-up.
Plan the Iteration(s): Outline a brief plan for how you will execute this approach. This might include:
A feature backlog or use case list (for FDD/RUP) and which features you’ll tackle in this assignment period.
The length of iteration(s) or time frame for the pilot. (For example, “Over the next 4 weeks, I will run two 2-week iterations to deliver and test two features.” Or “I will create an MVP of the new process within one month.”)
Roles and team: Identify who needs to be involved. Perhaps you need a domain expert or end-user to provide input (like FDD’s domain expert role) or a small team to help with development/testing. Secure their buy-in to participate.
Resources needed: Note any tools (e.g., a task board for tracking features, a prototype software, etc.) or resources required. Ensure you have access or a plan to obtain them.
In essence, treat this like a mini-project and develop a simple project charter for it. Since it’s agile, the plan can be lightweight – perhaps a one-page outline or a few slides to communicate to the team and stakeholders.
Execute and Monitor: Implement the plan. Do the work following the methodology:
If using FDD, go through the steps for the chosen feature(s): design the feature (maybe draw a quick model or flowchart), build the feature (develop the output, whether it’s a document, a piece of software, a new procedure, etc.), and then integrate it into the larger project context. Track your progress, e.g., use a simple Kanban board with features as cards to move from “Planned” to “Designed” to “Completed,” providing visibility.
If using AUP/RUP, define a mini life cycle. For example, have a short Inception (identify objectives and constraints for this mini-project), a brief Elaboration (design or prototype something to address a risk), then construct the solution and transition (deliver) it. Use iteration if possible – do a chunk, review with stakeholders, then next chunk. Keep a focus on risk and stakeholder feedback.
If using MVP, develop the MVP product or process. This might involve quick-and-dirty creation (doesn’t have to be perfect). Once ready, release it to a small group of end users or use it in a real setting. Collect feedback actively – through surveys, observation, or metrics.
Throughout execution, apply project control thinking: monitor schedule (did you finish your mini-iteration on time?), quality (did the feature/prototype work as intended?), and stakeholder engagement (are they giving feedback, are they satisfied?). If you encounter changes or obstacles, note how you addressed them (did you adapt scope? add another iteration? involve a sponsor to remove a barrier?).
Review and Reflect: At the end of the assignment period, evaluate the results:
What was delivered? (e.g., “Feature A and B were completed and demonstrated to users,” or “An MVP of the new client onboarding process was piloted with two clients.”)
What feedback or metrics were obtained? (e.g., “Users found Feature A useful but Feature B needs refining,” or “Both pilot clients completed the process successfully, one suggested an improvement to the form we provided.”)
How did the methodology help? Discuss the experience of using the chosen approach. For instance, “Breaking work into features helped me identify a requirement gap early” or “Using an MVP saved us effort because we discovered the idea had an issue before rolling it out fully.”
What challenges did you face applying this approach? Perhaps team members were unfamiliar with agile and needed coaching, or it was difficult to time-box the work, etc. How did you address these?
Link back to KSBs: Briefly note any KSBs you feel you demonstrated. For example, “This assignment showcased B11 Adaptability, as I had to adjust our plan after the first iteration based on user feedback. It also developed S8 Change Control in an agile setting, since I logged changes users requested and assessed their impact on the next iteration’s scope.”
Document these reflections. This could be in a short report or presentation form, as appropriate for your apprenticeship portfolio or as agreed with your mentor.
Presentation or Report: Prepare to share what you did and learned. The audience could be your line manager, mentor, or an assessment panel. Ensure you cover: the context and rationale (why you chose that project and method), what you did (the process and any deviations from plan), what the outcome was, and what you learned (both about the methodology and your own skills/areas for growth). Emphasize how this experiment could inform future project control practices in your organization – for instance, maybe it’s worth adopting agile approaches more broadly, or maybe a hybrid model is best.
By completing this assignment, you will demonstrate a practical understanding of iterative and agile methodologies. You’ll show that you can not only explain these concepts, but also apply them in a real-world setting to improve project outcomes. This kind of hands-on experience is invaluable – it brings to life the theoretical knowledge and connects directly to the competencies expected of a Project Controls Professional at Level 6.
Good luck with your “Agile in Action” project, and remember to keep the spirit of continuous improvement alive throughout the exercise. Even this assignment itself can be done iteratively – plan a little, do it, get feedback from your mentor, adjust, and continue
