B. Software Development · Software Development: Managing a Team Software ProjectManaging Your Own Time in a Team Project
B2.2 B2.1About 70 minutes
Learning goals- I can find my real weekly availability and book project time like appointments.
- I can turn team tasks into a personal plan using priorities, timeboxes and the next concrete action.
- I can keep a time log, compare my estimates with actual time, and improve my estimates.
- I can tell my team early when I am blocked or late, and ask for help in a useful way.
- I can use strategies against procrastination and protect my own well-being during a project.
Words to know
availability
The hours you can really give to the project in a week, after school, work, sport, family and rest.
timebox
A fixed block of time for a task (for example 90 minutes). When it ends, you stop, record where you are, and decide what is next.
next action
The very next physical step of a task, small enough to start right now, such as "write the first test for days_late".
time log
A record of what you worked on, when, and for how long.
estimation ratio
Actual time divided by estimated time. A ratio above 1 means the task took longer than planned.
blocker
Anything that stops you from continuing a task, such as waiting for a teammate's module or not understanding an error.
Eisenhower matrix
A grid that sorts tasks by urgent or not urgent and important or not important, to decide what to do now, schedule, keep short, or drop.
procrastination
Putting off a task even though you expect the delay to make things worse.
The team's plan runs on individual hours
Priya's schedule says that the loans module takes 5 days. But a schedule does not write code; Jordan does, in the hours he actually has between classes, his part-time job, hockey, other assignments and sleep. If each team member loses a few hours a week, the whole plan slips, and the burndown chart from the last lesson shows it.
The curriculum asks you to demonstrate the ability to meet project goals and deadlines by managing individual time during a group project (B2.2). Time management is not about working every spare minute. It is about knowing your real hours, deciding what matters most, doing it in focused blocks, measuring what happened, and telling your team early when something goes wrong.
Step 1: Know your real hours
Start with a week's calendar. Block out everything fixed: classes, work shifts, practices, family time, meals, travel and at least 8 hours of sleep. Then look at what is left and choose realistic project blocks, booked like appointments. A 60 to 90 minute block is long enough to get real work done.
Be honest. Most students overestimate their free time by forgetting other homework, chores and simply being tired. LendIt's plan counted 5 productive hours per person per week (see the lesson on work breakdown and estimates). Jordan's calendar below shows how he finds them.
Step 2: Decide what matters most
Not everything on your list deserves your best hours. The Eisenhower matrix sorts tasks by two questions: is it important (does it move the project toward its goals)? Is it urgent (does it have to happen now)?
- Important and urgent: do it now (a bug that blocks a teammate, a report due today).
- Important, not urgent: schedule it into a project block. Most real project work is here, and it becomes a crisis if postponed.
- Urgent, not important: keep it short (most messages and notifications).
- Neither: drop or delay it (often this is gold plating).
Step 3: Plan the week, then each block
Take your tasks from the team's board (the cards you own), order them by priority, and fit them into your blocks. A short program can do the fitting: it gives each task, in priority order, to the first block with enough room. (This greedy method is simple, not perfect, as the output shows.)
tasks = [("Fix B-11", 1, 1.5), ("Loans tests", 2, 3.0),
("Review Luc's PR", 2, 1.0), ("User guide draft", 3, 2.0),
("Tidy menu colours", 4, 1.0)] # (task, priority 1 = highest, hours)
slots = [("Mon", 1.5), ("Wed", 1.5), ("Fri", 1.5), ("Sun", 1.5)]
plan = {day: [] for day, _ in slots}
free = dict(slots)
for task, priority, hours in sorted(tasks, key=lambda t: t[1]):
for day, _ in slots: # first day with enough room
if free[day] >= hours:
plan[day].append(task)
free[day] -= hours
break
else:
print("Does not fit this week:", task)
for day, _ in slots:
print(day, plan[day], "free:", free[day])
Output: Does not fit this week: Loans tests and Does not fit this week: User guide draft, then Mon gets Fix B-11, Wed gets Review Luc's PR, Fri gets Tidy menu colours, and Sun stays empty with 1.5 hours free. The planner did exactly what it was told, and the plan is still bad: see the text below.
Look at what happened. The planner never put a task in a block that was too small, yet the two most important unfinished tasks are missing from the week and the gold-plating task got a block. The 3-hour and 2-hour tasks cannot fit in any 1.5-hour block. Big tasks must be split into block-sized pieces, each with its own next action; then the important work gets planned first. (The Challenge asks you to make the planner do this.)
Inside each block, use a timebox. Decide what you will try to finish, write down the next action ("write the test for a return on the due date", not "work on testing"), close the other tabs, put the phone in another room, and start. Many people work in focused stretches of about 25 to 50 minutes with a short break between them (the Pomodoro Technique uses 25 minutes). When the timebox ends, stop, write one line in your time log about where you are and what is next, and commit your work.
Worked exampleExample 1: Beating procrastination on a big task
Luc keeps putting off the user guide (4 hours estimated). Every time he opens the document he feels overwhelmed and does something else. Suggest a plan.
- Shrink the first step. The next action is not "write the user guide". It is "write the headings for the five menu options" (10 minutes).
- Timebox it. Book Wednesday 8:30 to 10:00 pm. Promise only to work on the guide for that block, not to finish it.
- Make it visible. Move the card to In progress on the team board and mention it at the stand-up. Saying "I'll have the outline by Thursday" creates a gentle commitment.
- Lower the bar for the first draft. Bullet points and screenshots are fine; tidy later.
- Reward and record. After the block, write the time and progress in the log, and take a real break.
A tiny next action, a timebox, a visible commitment and a rough first draft. Starting is usually the hardest part; once the headings exist, the rest follows.
Step 4: Measure what really happened
Keep a time log: date, task, minutes. It takes 30 seconds per block. At the end of the week, compare actual time with your estimates. The estimation ratio (actual ÷ estimate) tells you how optimistic you are, which is the most useful number for planning the next week. It also feeds the earned-value AC figure from the last lesson.
log = [("Loans tests", 3.0, 4.5), ("Due-date code", 2.0, 2.0),
("Fix B-11", 1.0, 2.5), ("Review PR", 1.0, 1.0),
("Overdue list", 4.0, 5.0), ("Status report", 0.5, 1.0)]
total_est = 0
total_act = 0
for task, est, act in log:
total_est += est
total_act += act
ratio = act / est
flag = " <-- much longer than planned" if ratio >= 1.5 else ""
print(f"{task:<14} est {est:3.1f} h actual {act:3.1f} h x{ratio:.2f}{flag}")
overall = total_act / total_est
print(f"Total: {total_est} h planned, {total_act} h actual, ratio {overall:.2f}")
print(f"Next time, multiply my estimates by about {overall:.1f}")
Output: one line per task with its ratio (three are flagged as much longer than planned), then Total: 11.5 h planned, 16.0 h actual, ratio 1.39 and Next time, multiply my estimates by about 1.4.
Worked exampleExample 2: What Jordan learns from his log
Use Jordan's log to answer: (a) What is his overall estimation ratio? (b) He plans 6 hours of tasks next week by his usual estimates. How many hours should he expect? (c) What pattern do you see, and what should he change?
- (a) 16.0 ÷ 11.5 ≈ 1.39.
- (b) 6 × 1.39 ≈ 8.3 hours, but he has 6 hours of blocks. He should either plan only about 6 ÷ 1.39 ≈ 4.3 hours of estimated work, or find more time.
- (c) Bug fixing and the status report took 2 to 2.5 times their estimates; coding tasks he had done before (due dates, reviews) were accurate. Unfamiliar tasks are where he underestimates.
- Change: estimate unfamiliar tasks with three points (O, M, P) and use the PERT expected time; split any task over 3 hours; and tell Priya at the stand-up that his capacity is about 4.3 estimated hours a week, so the team plan uses real numbers.
Ratio ≈ 1.39; expect about 8.3 hours for 6 estimated hours; underestimates unfamiliar work. Measuring turns "I'm always late" into a fixable pattern.
Step 5: Communicate early
In a team, your time affects everyone. Three habits make you a teammate people can rely on:
- The 30-minute rule: if you are stuck on the same problem for 30 minutes, ask for help, with specifics ("
load_loans raises ValueError on the second row; I've checked the date format; here's the traceback"). - Say it early: if a task will be late, tell the PM as soon as you know, with a new estimate. A warning on Tuesday can be planned around; a surprise on Friday cannot.
- Finish before starting: respect the board's WIP limit. Two finished tasks help the team more than four half-done ones.
And look after yourself. All-nighters produce bugs, not progress; the tester will find them later. Sustainable pace is a real agile principle, not a luxury.
Just for funParkinson's law, from a 1955 essay by C. Northcote Parkinson: "Work expands so as to fill the time available for its completion." A 90-minute timebox is a polite way of telling your work it cannot have the whole evening.
Hands-on activityProject step 11: Plan, timebox and log one week
You need: a paper or digital calendar, your team board, a notebook or spreadsheet for the time log, and Python.
- Map a real week from 3 pm to bedtime, including weekends. Block out fixed commitments and sleep. Book your project blocks.
- Sort your tasks in an Eisenhower matrix. Drop or delay one thing honestly.
- Plan the week: fit tasks into blocks (by hand or with the planner program, once you have fixed its bug). Write a next action for each task.
- Timebox and log every block for one week: date, task, planned time, actual time, one line on progress.
- Analyse the log with the time-log program: find your estimation ratio and the kind of task you underestimate most.
- Report at your next team meeting (or in your status report): your hours, your ratio, one change you will make.
- Reflect in two or three sentences in
docs/time-log.md: what helped you focus, what got in the way, what you will try next week.
What to look for: a calendar with sleep in it; tasks with next actions; a complete log (even for bad days); one specific change based on the numbers.
Your turn
1Why should you block out sleep and fixed commitments before booking project time?
So that project blocks are realistic: the hours that are left are the ones you really have. Booking project time first leads to plans that collide with work, sport or sleep and then fail.
2Sort into the Eisenhower matrix: (a) a teammate is waiting for your bug fix to continue; (b) writing tests for next week's module; (c) changing the program's font for fun.
(a) Important and urgent: do now. (b) Important, not urgent: schedule it. (c) Neither: drop or delay (it is gold plating).
3Turn "work on the storage module" into a next action.
Example: "Write save_loans so it writes the header row, and test it with an empty list." (Small, concrete, can start now.)
4A task was estimated at 2 hours and took 3. What is its estimation ratio?
5In the planner output, the two most important unfinished tasks (Loans tests, 3 h, and User guide draft, 2 h) are left out, while Tidy menu colours (priority 4) gets Friday's block. Why, and how do you fix the plan?
Every block is only 1.5 hours, so a 3-hour or 2-hour task cannot fit in any single block, however important it is, while a small low-priority task fits easily. The fix is to split large tasks into pieces of at most one block, each with its own next action (and to drop the gold-plating task). The total time is not the problem: the week has 6 hours.
6What is the 30-minute rule?
If you are stuck on the same problem for 30 minutes, ask for help, with specific details of what you tried.
7Why is telling the PM early about a delay better than working all night to hide it?
The team can adjust the plan (move tasks, add help, cut scope) while there is still time. Hiding it leads to surprises, tired mistakes and bugs, and the delay often happens anyway.
More practice: warm-up
A fixed block of time for a task; when it ends you stop, record progress and decide what is next.
Date, task, how long (and a short note on progress).
Anything that stops you continuing a task, such as waiting for a teammate or an error you cannot solve.
4Give one way to reduce distractions during a project block.
Any of: phone in another room; close unrelated tabs; turn off notifications; tell family you are in a work block.
5Name the law that says work expands to fill the time available.
More practice: on your own
1Amara has 5 hours of project blocks next week and an estimation ratio of 1.25. How many hours of estimated work should she plan?
5 ÷ 1.25 = 4 hours of estimated work (which should take about 5 real hours).
2Luc's log shows he works 3 hours on Sunday nights but only finishes about 1 hour of estimated work. Suggest two causes and two changes.
Causes: fatigue late on Sunday; distractions (phone, messages); unclear next actions; a hard task saved for last. Changes: move part of the work to shorter blocks earlier in the week; write the next action before starting; phone in another room; start the hardest task when he is freshest.
3Write a useful help request for this situation: your tests for can_borrow fail and you have tried for 40 minutes.
Example: "I'm stuck on test_three_out: can_borrow returns True for 3 loans. I've printed the loans list and out is 0 every time. I think the member numbers don't match (int vs string?). Could you look at it for 10 minutes before Thursday's block?" It gives the symptom, what was tried, a guess and a specific ask.
4Why does the time-log program flag tasks with a ratio of 1.5 or more instead of every task over 1.0?
Small overruns are normal and not worth worrying about. A threshold picks out the tasks that were badly underestimated, which are the ones that teach you something about how you plan.
5Explain how individual time logs help the project manager.
They give the actual hours (AC) needed for earned value and CPI, reveal each person's estimation ratio so the plan can use real capacity, and show early when someone is overloaded or blocked.
Challenge
1Change the planner so that, before planning, it splits every task longer than 1.5 hours into pieces of at most 1.5 hours named like Loans tests (1). Describe the change and the new plan.
Before the planning loop, build a new list: for each task, while its hours are more than 1.5, add a 1.5-hour piece and subtract 1.5; then add the remainder as the last piece; finally replace tasks with the pieces. New plan: Mon Fix B-11; Wed Loans tests (1); Fri Loans tests (2); Sun Review Luc's PR and User guide draft (2), every block full. Still waiting: User guide draft (1) and Tidy menu colours. The important work is now planned; with 6 hours of blocks and 8.5 hours of tasks something must wait, and now it is the right things.
2Jordan's ratio is 1.39 and the team plan assumed each person delivers 5 estimated hours a week. What does this mean for the project's schedule, and what should Priya do?
Each 5 estimated hours really takes about 7 real hours, so with 6 real hours a week Jordan delivers only about 6 ÷ 1.39 ≈ 4.3 estimated hours, about 14% less than planned. If the others are similar, the schedule is optimistic. Priya should re-forecast with the team's real ratios, use the buffer, and agree on scope changes (Coulds first) with the client now.
3Design a better task-fitting rule than "first block with enough room" and explain when it helps.
Largest task first into the block with the most room (or "best fit": the block whose free time is closest to the task size). Placing large tasks first prevents small tasks from filling every block and leaving no room for a big one. It helps when tasks vary a lot in size. Splitting a large task across two blocks also helps, as long as each piece has its own next action.
Quiz
1. Which task belongs in "important, not urgent"?
2. A task estimated at 4 hours took 6. What is the estimation ratio?
3. Which is a good next action?
4. You realize on Tuesday that your task will be two days late. What should you do?
5. Your estimation ratio is 1.5 and you have 6 hours of project time. How many hours of estimated work should you plan?
6. What is the main purpose of a time log?
Big idea: B2.2 asks students to meet project goals and deadlines by managing their individual time during a group project. This lesson covers finding real weekly availability, prioritizing (the urgent/important matrix), timeboxing and next actions, keeping a time log and learning from estimation ratios, and communicating early with the team.
How to help: Help your teen map a real week, including sleep, work and family commitments. Respect booked project blocks as you would an appointment. If they are stuck, ask "What's the very next step?" rather than "Why aren't you working?" Look at their time log with curiosity, not judgment: the goal is accurate numbers, not impressive ones.
Common difficulties:
- Overestimating free time and underestimating tasks (a ratio around 1.3 to 1.5 is very common).
- Waiting too long to ask for help or to report a delay.
- Big vague tasks that are easy to postpone.
- Trading sleep for project time, which usually costs more time in bugs than it saves.