Adds PD workshop to learn about estimating work (#229)

* Adds PD workshop to learn about estimating work

* Updates wording and adds more reflection questions

* a

Co-authored-by: Sally McGrath <[email protected]>

* Update paint-the-room/readme.md

Co-authored-by: Sally McGrath <[email protected]>

* Update paint-the-room/readme.md

Co-authored-by: Sally McGrath <[email protected]>

* Update paint-the-room/readme.md

Co-authored-by: Sally McGrath <[email protected]>

* Update paint-the-room/readme.md

Co-authored-by: Sally McGrath <[email protected]>

* Update paint-the-room/readme.md

Co-authored-by: Sally McGrath <[email protected]>

* Update readme.md

Rewords objectives to be active and testable

* Update paint-the-room/readme.md

* Update paint-the-room/readme.md

* Update paint-the-room/readme.md

---------

Co-authored-by: Sally McGrath <[email protected]>

paint-the-room/readme.md

@@ -0,0 +1,103 @@
+# Paint The Room 🧑‍🎨
+
+Understanding how to estimate tasks is a valuable skill that goes beyond just software development — it's useful in many areas of life and work. Whether you're planning a project at your job, managing a household renovation, or coordinating a group activity, the ability to break down a large task, consider hidden complexities, and accurately estimate effort can reduce stress, and help ensure success. 
+
+Let's take a real-world example.
+
+Your project manager comes to you and says he has a customer who wants you to develop an app. He wants to know how quickly can you deliver it and how much should we charge the customer. You've developed a couple of similar apps so you tell your project manager you think it will take two developers one month and cost 10,000MD (made up dollars). 
+
+Suddenly three weeks into the project you realize that the app wasn't as straightforward as you initially thought: it will be at least another month until you will be close to done, and will cost another 8,000MD at least. Your project manager is furious, your customer is furious, and you are stressed because of the pressure to deliver. 
+
+How to avoid this situation?!
+
+Today we will learn some effective techniques that help us plan large complicated tasks through an interactive game.
+
+## Learning Objective 🧐
+
+We will play a game to learn important techniques to help us estimate our work. After this workshop, participants will be able to:
+
+- [] Use relative estimation to compare the effort involved in two different tasks.
+- [] Assign story points to tasks based on complexity and effort.
+- [] Elaborate on user stories by asking questions, raising assumptions, adding necessary details and clarifications.
+- [] Split large tasks into smaller, more manageable stories.
+- [] Participate in Planning Poker to collaboratively estimate tasks.
+- [] Explain what a backlog is.
+
+## Set up 🌼
+
+- Split into groups of no more than  5
+- You will need some paper and something to  write with.
+
+## The game 🎲
+
+Your team has been tasked with painting the room you are in. The customer’s vague requirement is: “Please paint the room.” Before you begin you need to tell your customer how much it will cost and how long it will take. If you underestimate the cost or time it will take, you will lose money. If you overestimate the cost or the time it will take by too much, you will lose the job to a competitor!
+
+Your initial project backlog (work that needs to be done) consists of:
+
+- Paint the north wall
+- Paint the south wall
+- Paint the east wall
+- Paint the west wall
+- Paint the ceiling
+- Paint the floor
+
+### Part 1: Establish the Anchor Feature
+
+1. Choose one wall in the room that appears to require a medium level of effort compared to the others. 
+
+    This wall serves as the anchor for all future relative estimations.
+
+2. Choose a scale. Some people use [T-shirt sizes](https://asana.com/resources/t-shirt-sizing) (XS, S, M, L, XL), some use points (1-5). Whatever the scale that you as a group choose, the anchor wall will be in the middle of your scale. 
+
+    "[Story Points](https://asana.com/resources/story-points)" are abstract and are used to estimate the effort involved, not the time.
+
+### Part 2: Estimate One Wall
+
+1. [Planning poker ](https://planning-poker-agile.web.app/about-planning-poker)time! Pick Another Wall. Everyone write down your estimate in comparison to your anchor wall. Wait until everyone is ready and reveal your estimates at the same time. 
+
+2. Discuss Estimates:
+
+    Focus on the high and low estimates. Ask participants to explain their reasoning.
+
+3. Clarify Assumptions: Do we need masking tape for trim and windows? Should we remove electrical outlet covers? Is the prep work done in advance?
+
+ ### Part 3: Backlog Refinement
+
+1. [Backlog grooming](https://asana.com/resources/backlog-refinement): What new tasks were discovered upon discussion of the assumptions.
+  Examples:
+- Remove electrical outlet covers
+- Apply masking tape around windows
+- Purchase supplies
+- Cleaning up
+
+2. Story Elaboration: Refine the backlog by adding details about preparation, tools, or other hidden requirements.
+
+3. Refinement: If the task involves more complexity than anticipated, split the story into smaller tasks and provide estimates (e.g., remove fixtures, paint ceiling, reinstall fixtures).
+
+### Part 4: Estimate the Rest 
+
+1. Repeat Parts 2 (Planning Poker) and 3 (Backlog Refinement) for the other walls, floor, and ceiling.
+
+### Part 5: Reflection
+
+#### Key Takeaways:
+
+The value of Planning Poker is in the <strong>conversation</strong>. As everyone shares their assumptions, the team gains a better understanding of the scope of work.
+
+Relative estimation helps teams avoid anchoring on time and encourages thinking about effort in comparison to other tasks.
+
+Backlog refinement happens naturally as the team discusses assumptions and new tasks emerge.
+
+#### Reflection:
+
+As a large group come together and discuss:
+
+- What were some hidden assumptions your team made during the estimation process?
+- How did those assumptions affect your initial estimates, and how were they uncovered during the discussion?
+- Did discussing your estimates with the group help you refine your thinking or challenge your assumptions? How?
+- Why is it beneficial to break large tasks (like "paint the room") into smaller, more manageable stories?
+- How does splitting stories help teams deliver value more quickly or manage risk better?
+- How does regularly refining the backlog contribute to a more accurate project plan?
+- Why might relative estimation (comparing tasks to each other) be more useful than absolute estimation (assigning exact hours/days)?
+- What challenges did you encounter when using relative estimation, and how did you overcome them?
+- Why might this work better for estimating how much work a team can accomplish in a week?