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.

We will play a game to learn important techniques to help us estimate our work. After this workshop, participants will be able to:

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 (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” are abstract and are used to estimate the effort involved, not the time.

Part 2: Estimate One Wall

1. 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: 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 conversation. 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?

CRUD 101

Requirements

Today we will build a CRUD API. CRUD stands for Create, Retrieve,* U*pdate, Delete. If you think about it, this is what most applications do:

Create some “resources” Retrieve them (GET them) Update them Delete them

🎯 Workshop Objective

Our API will manage Beyoncé albums. It will:

Create a new album, Retrieve a list of albums or a single album, Update an existing album’s information Delete an album

We will build these endpoints:

1. GET /albums should return all the albums
2. GET /albums/:albumId should return a single album (that matches the passed albumId)
3. POST /albums should save a new album
4. DELETE /albums/:albumId should delete the album (that matches the passed albumId)

1. GET /albums should return all the albums

In server.js, create a GET /albums endpoint that returns all the albums. Some albums have been provided for you in albums.json.

app.get("/albums", (req, res) => {
  res.send(albumsData);
});

🧪 Run and test

1. npm run dev
2. Open Postman
3. Make a GET request to http://localhost:3000/albums

2. GET /albums/:albumId should return a single album (that matches the passed albumId)

Sometimes, we do not want to list all the information in one request, maybe we only want to get the information related to a single album. Imagine if we have a page to display the details of one album. We could call the server and get all albums then filter the one we need client-side. It would be more effective to tell the server to just return the one album we are interested in.

We will now add a new endpoint to return only a single album GET /albums/:albumId. In this case, albumId will tell us what album we can return. The call will be GET /albums/10 and that will return the album with that has albumId: "10".

This endpoint has something different. The endpoint /albums/:albumId has a dynamic part. The albumId will vary depending on what the client sends.

In server.js, create a GET /albums/:albumId endpoint that returns a single album. The albumId will be passed as a parameter in the URL.

app.get("/albums/:albumId", (req, res) => {
  const albumId = req.params.albumId;
 // now find the given album from the `albumsData` using the `albumId`
 // finally send the album you found back to the client
});

🧪 Run and test

1. Save your changes
2. Make a GET request to http://localhost:3000/albums/10
3. Try changing the id in the URL and calling the endpoint again. What do you see?

3. POST /albums should save a new album

In order for our server-side to receive and use the data sent by the client, we will need to install and use a middleware.

The JSON middleware makes it easy for our route handlers to read JSON data from the request. If the Content-Type request header indicates that the request body contains JSON data then the middleware calls JSON.parse to convert the request body into a JavaScript data structure.

To register the JSON middleware, add the following to the server code:

app.use(express.json()); // before our routes definition

In server.js, create a POST /albums endpoint that saves a new album. The album will be passed as a JSON object in the request body.

app.post("/albums", function (req, res) {
  const newAlbum = req.body;
  albumsData.push(newAlbum);
  res.send("Album added successfully!");
});

{
  "albumId": "13",
  "artistName": "Beyoncé",
  "collectionName": "B'Day (Deluxe Edition)",
  "artworkUrl100": "http://is5.mzstatic.com/image/thumb/Music/v4/6c/fc/6a/6cfc6a13-0633-f96b-9d72-cf56774beb4b/source/100x100bb.jpg",
  "releaseDate": "2007-05-29T07:00:00Z",
  "primaryGenreName": "Pop",
  "url": "https://www.youtube.com/embed/RQ9BWndKEgs?rel=0&controls=0&showinfo=0"
}

4. DELETE /albums/:albumId should delete the album (that matches the passed albumId)

This means that DELETE /albums/2 should delete an album with the id 2 and return 200 with JSON { success: true } to the user.

The code will look like this

// notice .delete
app.delete("/albums/:albumID", function (req, res) {
  console.log("DELETE /albums route");
});

Can you work out how to remove an album using this code?

Acceptance Criteria

• I have written a server that can handle the following requests:
  • GET /albums
  • GET /albums/:albumId
  • POST /albums
  • DELETE /albums/:albumId
• I have used Postman to test my server

Resources

• Express
• Express Cheatsheet

Components are Functions

Today we’re going to think some more about components. We’re going to build a page using a design system and we’re going to collaborate on a sub branch, feature branch workflow. We’re going to identify the difference between HTML and the DOM using Devtools. And we’re going to create new DOM nodes using JavaScript functions. Oh my goodness, it’s so many things! That’s why it’s best to do this workshop after you’ve done a couple of modules of https://programming.codeyourfuture.io/

And in particular, these workshops:

• Git
• Devtools
• Components 101

If you missed these workshops in your cohort, it’s a good idea to try to do them in the week (online) first. Record your session for people that can’t attend. Everyone should try to do the workshops first, either in groups or solo if necessary.

The overall mission is to compose “components” / groupings of HTML elements to build a page in together.html.

But this time, we’re going to use JavaScript functions to build our components.

Visualise this Git workflow

Get set up to work in teams

Next, divide the class into four teams: header, footer, card, menu. Use the team generator to help you do this.

Set a whole class timer for 10 minutes.

git switch --create feature/cohort-component

Find your docs

Set a whole class timer for 10 minutes.

Together separately

Set a whole class timer for 30 minutes.

Review and merge

Now we’re going to review each other’s work and merge to our cohort branch.

Your COHORT branch is your cohort name. You’re working in your COHORT branch and not in main. Open your pull request to your COHORT branch.

Visualise this Git workflow

Set a whole class timer for 20 minutes.

Acceptance Criteria

• We have worked in teams to build a page using JavaScript components and modules
• We have used an advanced sub-branch feature branch workflow to collaborate
• We have reviewed each team’s PR