A Project in a Team

In Grade 8 you learned to start with people, not with an idea: interview the people who have a problem, about what they do now, and watch them do it Grade 8: Start with people. Then sum it up in a problem statement that names a user and a need, never a solution. A Grade 10 team does all of that, and then goes further.

Four Grade 10 students, Sita, Bikash, Anil and Ritu, asked around their village for a problem worth solving. The secretary of the milk cooperative, Kamala didi, told them about her two evenings with the calculator. They went to watch the morning collection, and then spent an evening with her and the register. Here is what they wrote down:

• About 60 farmers bring milk twice a day, so a day has about 120 deliveries. Each line in the register has the date, morning or evening, the farmer’s number, the liters and the fat reading.
• The cooperative pays by the milk’s fat: Rs 15 a liter for each 1% of fat, so a liter with 4.0% fat earns Rs 60. (Real cooperatives’ rates are set differently, and most also count the other solids in the milk; this rule keeps the sums simple.)
• Kamala didi adds up each farmer’s 15 days and rounds the payment to the nearest rupee once, at the end.
• At six in the morning there is no computer at the collection center, her hands are wet, and the queue is long. The register stays.
• The office has one old laptop, shared with the accountant. Power cuts happen. The internet is slow and often off.
• Farmers ask her, “How much this time?” days before payday. Some read Nepali better than English; a few can’t read well at all.
• Two farmers said, quietly, that they don’t want others to know how much they earn.

Their problem statement:

Kamala didi spends two evenings every fifteen days working out about 60 farmers’ payments by hand, and when a farmer doubts a sum, neither of them can easily check it.

It names a user and a need. It doesn’t say “we will write a Python program”. That keeps the team open to the best answer, which might even be a better paper form.

Requirements you can test

In Grade 9 you wrote a design brief, with an “it must” list Grade 9: A design brief. For a team, the list needs two more things. Each requirement gets a number, so that everyone, in every document, means the same line by “R3”. And each one is written so that a test can show whether it is met.

There are two kinds of requirement:

• A functional requirement says what the product must do: a job it carries out. “Work out each farmer’s payment for any 15 days.”
• A quality requirement (also called a non-functional requirement) says how well it must do it, or in what conditions: how fast, for whom, on what device, how safely. “Work on the office laptop with no internet.”

The team’s list, after a second talk with Kamala didi:

And a third list, not this project: farmers checking their totals on their phones, the cooperative’s loans and savings, the accounts. Each was a good idea; each was too big for six weeks, or not what Kamala didi asked for. Writing them down stops the team arguing about them again.

A team of four can’t keep a plan in one person’s head. Before building, a software team writes a design document: a short, shared description of what they will build and how, which every member has read and agreed to. It is the team’s memory. When two members remember a decision differently, the document settles it. When someone is ill for a week, it tells them where things are. And when the user asks “why does it do that?”, the answer is written down.

A school project’s design document can fit on two pages. Here is the milk team’s, a little shortened:

MILK PAYMENTS: design document, version 5 (Magh 24, 2083)Team: Sita (user lead), Bikash (builder), Anil (tester), Ritu (record keeper) 1. USER AND PROBLEMKamala didi, secretary of the cooperative, spends two evenings every15 days working out about 60 farmers' payments by hand. (Interview notes:notes/interviews.txt) 2. REQUIREMENTSMust: R1 to R5. Quality: Q1 to Q4. (Each with its test: requirements.txt)Not this project: farmers' phones, loans and savings, the accounts. 3. DESIGNHow it is used: Kamala didi types each evening's register page into the  entry program on the office laptop; on payday she prints the slips.Entry program: asks for the farmer's number first, then shows the name  back; M or E; liters; fat. Saves after every delivery. (Sketches:  notes/entry-on-paper.txt)Data: deliveries.csv, one row per delivery:  date     text, YYYY-MM-DD in Bikram Sambat, e.g. 2083-10-01  session  M or E  farmer   whole number, 1 to 99, must be in farmers.csv  liters   number, more than 0, at most 50, one decimal place  fat      number, 2.5 to 10, one decimal placeModules, each with its owner:  records.py (Anil): read and save deliveries; check each entry.  payments.py (Bikash): payment(liters, fat) gives rupees, not rounded;    totals(rows, start, end) gives {farmer: [liters, rupees]}.  slips.py (Ritu): one farmer's slip, in Nepali and English.  entry.py (Sita): the entry program Kamala didi uses. 4. TESTINGtests.py holds tests T1, T2 ... written from the requirements. Run allof them after every change. User tests: weeks 3 and 5 (see the plan). 5. RISKS AND LIMITSWrong numbers typed: R4 checks and the name shown back.Laptop stolen or broken: a copy on the pen drive every Friday.Farmers' earnings are private: only the secretary and the accountantuse the laptop; each slip shows one farmer.It doesn't replace the register: the register is the record. 6. PLAN AND DECISIONSTask board: on the classroom wall, copied into tasks.txt each Friday.Decisions: Magh 2: no phones this time (see "Not this project").Magh 8: only a file's owner changes it; others send the ownertheir change. Magh 22: round each farmer's payment once, at theend, as Kamala didi does (found in the user test; R3 rewritten).

Every section answers a question the team would otherwise argue about: what we are making and for whom, how we will know it is right, how the parts fit, who owns what, what could go wrong. The data part is a data dictionary, as in Unit 3 Grade 10: A data dictionary. The module list comes from Unit 1 Grade 10: Modules: splitting the program into modules lets four people build at once, each in their own file.

A design document changes as the team learns: this one is version 5, from after the first user test, and you will see later in this unit why its last two decisions were added. Give it a version number and a date, and add each decision with its date, so nobody is working from an old copy.

The whole project follows a workflow: a set of steps the team has agreed on, each of which leaves something written behind, as Figure 8.2 shows. Agreeing the workflow at the start is part of the plan: everyone knows what comes next, and what “finished” means for each step.

Agreeing how the parts fit

Look again at the module list. Bikash will write payments.py; Ritu, at the same time, will write slips.py, which calls Bikash’s totals(). She can’t wait for him to finish. So the design document says exactly how the two parts meet: the function’s name, what it is given, what it gives back, and in what units. This is called an interface. As long as both keep to it, each can build and test their part alone, and the parts will fit when they are joined.

The interface also says what each part does not do. payment() returns rupees not rounded; rounding happens once, at the end, as Kamala didi does it. If Bikash rounded inside payment() and Ritu rounded again on the slip, every farmer with many small deliveries could be paid a rupee or two wrong, and both of them would think their own part was fine.

In Grade 8 you met the four roles: user lead, builder, tester, record keeper Grade 8: Working as a team. A role says who makes sure a job gets done, not who does all of it. In a Grade 10 team, two more things are written down:

• An owner for each part: each module, each document, each test file. The owner of a file is the one who changes it, or agrees to each change to it. (You will see why later in this unit.)
• How the team decides. About what users need, the users decide: try both ideas with them. About whether something works, the tests decide. Everything else, the team agreement says how: perhaps each member speaks once, the quietest first, and then the team votes.

Tasks that wait for each other

A plan is a list of tasks, each small enough for one person to finish in about a week (about three periods), each with an owner and a date. But tasks can’t simply be shared out in any order, because some must wait for others. Nobody can build the entry program before Kamala didi has tried it on paper; nobody can test with users before there is something to test. A task that must be finished before another can start is called a dependency of that task.

Follow the waiting from the first task to the last, and some chains are longer than others. The longest chain sets the earliest the project can possibly finish, however many people work on it. A task on that chain that slips by a week makes the whole project a week late. A task off it has room to move.

Notice what the widget showed: in weeks 1 and 2, three of the four members have nothing on the plan, because everything waits for the interviews and the design document. They aren’t idle in a real project: they come to the interviews, read about how other cooperatives pay, and learn the tools. But adding more people to those weeks wouldn’t make the design document come sooner.

The task board

A plan on paper goes out of date in days. Most software teams keep theirs on a task board: a board with three columns, To do, Doing and Done, and each task on a card or a sticky note with its owner’s name. When you start a task, move its card to Doing; when it is finished, to Done. Anyone can see at a glance what is happening, what is stuck, and who has too much.

Two rules make a task board work:

• Done means done. Agree, in the design document, what “done” means for every task. For the milk team: it works; its own tests and all the old tests pass; the change log says what changed; and another member has read it. A card that is “nearly done” stays in Doing.
• Few cards in Doing. Each member works on one task at a time and finishes it before starting another. Ten half-finished tasks help nobody.

At the start of each period, the team meets for five minutes, standing up so that it stays short. Each member says three things: what I finished, what I will do next, and what is in my way. “What is in my way” matters most: a member stuck on a problem for a week, without telling anyone, is how projects fall behind.

Grade 9 gave you the principles of human-centered design: know the users, their task and where they do it; involve them all the way through; let what they do decide the changes; go round again Grade 9: Designing for people. This section is about using them: turning what you saw into design decisions, each one traceable to something a user did or said.

The milk team made a table: what they saw, and what it means for the design.

Each row follows a principle that usability experts use. Jakob Nielsen, a Danish researcher, wrote ten of them in 1994, called his usability heuristics; five of them are in that table:

• Match the user’s world. Their words, their order, their way of working: the register’s order, not the programmer’s.
• Show what is happening. After every action, say what happened: “Saved: 12 Hari Shrestha, morning, 3.2 liters, 4.1%.” Silence leaves a user wondering.
• Prevent mistakes. Better than a good error message is a design where the mistake can’t be made, or is caught at once.
• Let people recognize instead of remember. Show the farmer’s name; don’t make her remember who number 37 is.
• Let people undo. A mistake that can be put right easily is not frightening.

Before writing any code, the team tried the design on paper. For a program that asks questions, a paper test is simple: Sita read each question aloud from a card, exactly as the program would print it, and Kamala didi answered from a real register page. It took twenty minutes, and it found the biggest problem of the whole project: their first design asked for the farmer’s name.

Here is the entry program after that test, as Kamala didi sees it:

Milk deliveries for 2083-10-01, morning. Press Enter on a blank line to stop. Farmer number: 12   Hari ShresthaLiters: 3.2Fat: 41   Fat must be between 2.5 and 10. Did you mean 4.1?Fat: 4.1   Saved: 12 Hari Shrestha, morning, 3.2 liters, 4.1% fat.   (37 today) Farmer number:

The team didn’t build all four modules and then join them. They built the thinnest version that went all the way through, first: one farmer’s deliveries in, one farmer’s total out. Then, stage by stage, every farmer, the 15 days, the checks, the slips. After each stage they had a program that worked, a little more of it each time.

Here is the heart of the program, payments.py, with the team’s tests under it. The tests were written in week 3, from the requirements and from sums worked out by hand, before the code was finished. Run it.

RATE = 15    # rupees a liter for each 1% of fat: this cooperative's rule def payment(liters, fat):    """What one delivery earns, in rupees, not yet rounded."""    return liters * fat * RATE def totals(rows, start, end):    """Each farmer's liters and payment for the days start to end."""    result = {}    for date, session, farmer, liters, fat in rows:        if start <= date <= end:            if farmer not in result:                result[farmer] = [0, 0]            result[farmer][0] = result[farmer][0] + liters            result[farmer][1] = result[farmer][1] + payment(liters, fat)    return result def check(name, rows, farmer, want_liters, want_rupees):    """Run one test: compare a farmer's total with the right answer."""    got = totals(rows, "2083-10-01", "2083-10-15")[farmer]    liters, rupees = round(got[0], 1), round(got[1])    result = "pass" if (liters, rupees) == (want_liters, want_rupees) else "FAIL"    print(name, result, "| got", liters, "liters, Rs", rupees) # The tests, written from the requirements before the codecheck("T1", [("2083-10-01", "M", 12, 4.0, 4.0)], 12, 4.0, 240)check("T2", [("2083-10-01", "M", 12, 3.2, 4.1),             ("2083-10-01", "E", 12, 2.4, 4.5)], 12, 5.6, 359)check("T3", [("2083-10-01", "M", 12, 3.0, 4.0),             ("2083-10-01", "M", 7, 5.0, 3.6)], 7, 5.0, 270)check("T4", [("2083-09-30", "E", 12, 3.0, 4.0),             ("2083-10-01", "M", 12, 2.0, 4.5)], 12, 2.0, 135)

T1 pass | got 4.0 liters, Rs 240T2 pass | got 5.6 liters, Rs 359T3 pass | got 5.0 liters, Rs 270T4 pass | got 2.0 liters, Rs 135

Each test is a chosen input with an answer worked out by hand: T1 an ordinary delivery; T2 one farmer twice in a day, the case most likely to go wrong; T3 two farmers, to show their totals are kept apart; T4 a delivery the day before the 15 days, which must not be counted. Dates are written 2083-10-01, year, month, day, with zeros, so that comparing them as text puts them in date order. Rounding happens once, in check(), at the end, as R3 says.

Dated versions and a change log

Every time a stage worked and its tests passed, the team kept a copy of the whole program folder, named with its version and date: milk-v04-2083-10-10. And Ritu, the record keeper, wrote one line in the change log: a dated list of every change, who made it, and why.

v8  Magh 19  Anil    Copy everything to the pen drive (risks)v7  Magh 17  Sita    The entry program, showing the name back (R1)v6  Magh 14  Ritu    A slip for each farmer (R5)v5  Magh 12  Bikash  Made totals() shorterv4  Magh 10  Anil    Refuse impossible entries, with a message (R4)v3  Magh 8   Sita    Count only the 15 days chosen (R2)v2  Magh 5   Bikash  Totals for every farmer, morning and eveningv1  Magh 3   Bikash  payment() and one farmer's total

Kept versions let the team go back to one that worked. The change log tells them what each version changed. Together, they turn “it’s broken” into “this change broke it”.

On Magh 19, before the user test, Anil ran all the tests on version 8, and T2 failed: Hari Shrestha, with a morning and an evening delivery (3.2 liters at 4.1% fat and 2.4 liters at 4.5%), was shown 5.6 liters, which is right, but only Rs 162 instead of Rs 359. Nobody remembered changing anything about payments. Find the change that broke it.

Halving the versions still possible, again and again, finds the bad change among 8 versions in at most 3 runs, and among 1,000 in at most 10. It is the same idea as binary search Grade 8: Grade 8, used on history. It only works because the old versions were kept and the tests could be run on any of them.

Two people, one file

Early in the build, before the team had agreed that only a file’s owner changes it, this happened. On Magh 6, Sita and Bikash each copied payments.py from the pen drive to work at home. Sita added the 15-day check; Bikash fixed a spelling in a message. Sita copied her file back in the evening. Bikash copied his back the next morning, over hers. Her whole evening’s work was gone, and nobody noticed until she ran the program that night. She did it all again (version 3), and the team wrote a new decision into the design document.

This is called a lost update: two people change copies of the same thing, and the second one saved wipes out the first. It is one of the oldest problems of working together on files. Without special tools, the cures are rules:

• One owner per file. Only the owner changes it. Anyone else sends the owner their change, written out.
• Split the work so it doesn’t overlap. Modules help: four people in four files can’t overwrite each other.
• Copy back, then check. Before saving your file over the shared one, check that the shared one is still the version you started from. If not, join the two by hand, carefully, and run all the tests.

Version control tools such as git (Grade 12) do all of this for a team automatically: they keep every version, notice when two people have changed the same file, and help join their changes. The ideas are the same as the team’s rules.

You know how to test with users: give them a real task, watch, don’t help, write down what happens in their words Grade 8: Testing with real users. At Grade 10, you also measure, so that version 2 can be compared with version 1 in numbers, not only impressions. Four measures are used by usability testers everywhere:

• Success: did they finish the task? How many of the testers did?
• Time: how long did it take?
• Mistakes: how many wrong entries, and how many did they notice and correct?
• Help: how many times did they need to ask?

And one question at the end, the same every time: “How easy was that, from 1 (very hard) to 5 (very easy)?”

In week 5, with version 5’s mistake fixed, the team tested the program with its users. They called it version 1 of the product: the numbers in the change log count every small step, while these count what the users get. They tested it with Kamala didi (her task: enter one evening’s register page, 58 deliveries, then print three slips) and with five farmers (their task: from your slip, tell us what you will be paid, and for how many liters). Their results:

And their findings, in the users’ words where they had them:

• A power cut came in the middle of the test. The program saved after every entry, so nothing was lost. (Q4: passed, by luck, in a real test.)
• One mistake was not corrected: she typed farmer 21 for 12, and didn’t look at the name. “I know the numbers. I don’t look.”
• She asked for help twice: both times to correct a delivery she had typed wrongly. There was no way to do it.
• Two farmers couldn’t read their slips: the totals were labeled in English.
• A slip said Rs 1,065. Kamala didi worked it out herself and got Rs 1,064. The farmer, she said, would certainly ask.

When the requirement was wrong

The rupee between Rs 1,065 and Rs 1,064 took the team an evening to understand. The farmer had brought 1.1 liters at 4.3% fat every morning for 15 days. Each delivery is worth 1.1 × 4.3 × 15 = Rs 70.95. Version 1’s slips rounded each delivery to Rs 71, then added: 15 × 71 = Rs 1,065. Kamala didi adds the exact amounts first, Rs 1,064.25, and rounds once: Rs 1,064.

So the bug wasn’t in the code’s sums; it was in what the team had written down. R3 said “agrees with her hand calculation”, but nobody had written down how she rounds, and Ritu’s slips rounded each line, to make the slip look tidy. The team changed R3 to say “rounded once, to the nearest rupee, after adding the exact amounts”, added the interface note you read earlier (“payment() returns rupees not rounded”), and wrote test T6: 15 deliveries of 1.1 liters at 4.3%, Rs 1,064. Testing with users doesn’t only find bugs in a program. It finds mistakes in the requirements, which no test written from those requirements could find.

Testing finds problems one by one. Evaluating asks the bigger question: does the product do what it was meant to, for the people it was meant for? You judge it against its specification, the numbered requirements, one line at a time, with evidence for each: a test result, a measurement, something a user did. Not “we think so”.

Grade 9 named four things to evaluate Grade 9: Evaluating. Their standard names are:

• Correctness: does it give the right answers? Evidence: the tests.
• Effectiveness: does it solve the user’s problem, better than what they did before? Evidence: measures of the old way and the new.
• User experience: can its users use it well, without help, and do they want to? Evidence: the user tests.
• Responsible design: privacy, honesty, fairness to everyone, safety Grade 9: Responsible design. Evidence: who sees what, who is left out, what harm a mistake could do.

Here is the start of the milk team’s evaluation report, for version 2:

An honest evaluation says “partly” where it is partly, and says how sure the evidence is. Sixty-one farmers’ totals agreeing is strong evidence for R2; one payday without a dispute is weak evidence that disputes have ended.

After the evaluation, the team listed every finding, decided what to change, and recorded why. Improving is not doing everything anyone asks: some requests make the product worse for its users.

The last request needs care. Watered milk is a real problem for cooperatives, and a sudden drop in fat can be a sign of it. But a drop has other causes too: a sick buffalo, a cow that has just calved, a change of feed, the season, a fat tester that needs cleaning. A program that cut a farmer’s pay on its own would punish honest farmers for things they couldn’t help, and they would only find out on payday, with nobody to explain to. So the team designed it the other way round: the program shows the drops, a person asks the farmer, and only a person decides. They wrote that rule into the design document, as a decision with its date and reason.

After every change, the team ran all the tests again, added a test for each new rule, and tested version 2 with Kamala didi and three farmers, two of whom hadn’t seen version 1. The results went into the evaluation report you read above.

Kamala didi’s evenings are now shorter, but she still types every delivery from the register. One evening Ritu asked: “Could an AI just read the register from a photo?”

An emerging technology is one that is new or changing fast, whose uses are still being found and whose effects aren’t yet well known. As of 2026, examples include AI that reads and writes text and pictures, drones, and cheap sensors joined in the Internet of Things (Unit 5). Unit 9 looks at emerging technologies and society in general. Here, you will do what a team does when one might help with its own problem: design a conceptual solution, on paper, without building it, and weigh its benefits and harms before anyone spends money or trusts farmers’ pay to it.

The idea, step by step

Ritu wrote the concept as steps, so that everyone could see where a person is involved:

1. Each evening Kamala didi photographs the day’s register page with her phone.
2. A program that reads handwriting turns the photo into a table: farmer, liters, fat for each line.
3. The table opens on the laptop beside the photo of each line, with any number the program is unsure of marked.
4. She checks every line against the register and corrects what is wrong. Nothing counts until she has checked it.
5. The checked lines are saved, exactly as typed ones are.

Step 4 is where most of the thinking went. A handwriting reader makes mistakes, as every AI model does (Unit 7), and here a mistake is money: a 7 read as a 1 pays a farmer for 1 liter instead of 7.

Weighing the consequences

A good way to think through a new technology’s effects is called consequence scanning, a practice published in 2019 by Doteveryone, a British organization that worked on responsible technology. A team asks three questions:

1. What are the intended and the unintended consequences of this product?
2. Which good consequences do we want to focus on?
3. Which consequences, especially the harmful ones, do we want to reduce?

The second half of question 1 is the hard part, because unintended consequences are the ones nobody planned. List who will be affected (the users, the people the data is about, people who are left out, people whose work changes) and ask, for each, what could happen to them.

Then the team set out, for each group of people, what they would gain and what they could lose:

Deciding

The team didn’t decide yes or no. They proposed a test, the way a careful team treats any emerging technology: photograph three old register pages (about 500 numbers whose right values are known), run them through two handwriting readers, and count the errors. If the readers get even 1 number in 100 wrong, Kamala didi would correct about 3 or 4 a day, and checking every line would still save her time only if reading the photo is much quicker than typing. The measurement would decide, along with the cooperative’s committee, who would have to agree to farmers’ data going to an outside service. They wrote all of this as a one-page concept in their design document, under “Not this project”.

You know how to present a project: the need, the product working, what testing changed, its limits, the credits Grade 8: Presenting your project. In Grade 10, the presentation also shows the team’s workflow: a reader of your documents should be able to follow each decision from what a user did to what the product does.

• What changed, and why. Version 1 beside version 2, each change linked to its evidence: “Kamala didi needed help twice to correct a delivery, so version 2 lets her correct one.” Show a measure going down or up.
• What each member did. Each member says, in their own words, what they owned and did, and one thing they learned. The change log and the task board are the evidence.
• The evaluation, honestly: what is met, what is partly met, what is left.
• The emerging-technology concept: the idea, its benefits and harms, and what test would decide it.
• A backup. If the power goes or the laptop won’t start on the day, have screenshots or a printed run of the program. A presentation that depends on one machine working is a risk you can plan for.

If the product will really be used, hand it over. A handover is more than leaving the program on the laptop. It is a short guide for the user, and an agreement about who looks after the product from now on:

MILK PAYMENTS, version 2 (Phagun 4, 2083): for Kamala didi Every evening: open "Milk entry" on the desktop. Type each line of  the register. To stop, press Enter on a blank line.To correct a delivery: choose 2 on the menu.Payday: choose 3, type the 15 days, and print the slips.Every Friday: choose 4 to copy everything to the pen drive. Keep the  pen drive at home, not in the office. Known limits: a wrong farmer number that exists is accepted; look atthe name. The register is still the record: if the program and theregister disagree, the register is right. If something goes wrong: Anil (98XXXXXXXX), until the end of Chaitra.After that: the computer teacher at our school has a copy of the program,this guide and the design document.

This is the Grade 10 project, about 17 periods over six or seven weeks, in a team of three or four. It brings together what you have learned this year: programs in modules (Unit 1), data and its dictionary (Units 3 and 4), finding problems (Unit 6), and judging AI (Unit 7).