Donation Portal scenario walkthrough

In a lot of projects, the hardest question is not what to build but who gets to say. Donation Portal is the scenario about that. A food bank has an executive director who wants every voice heard, a board that has opinions, a major donor with a view and a volunteer coordinator with a list. One team, one deadline and a lot of people who believe they have a vote.

The project

Riverside Food Bank has $35,000, twelve weeks and four planned sprints. A grant expires with the giving season, so the date is not negotiable. The portal has to take gifts online, in a way people trust with their money.

The backlog is full of things that matter to somebody. Choose a gift amount and pay by card on a secure page. Give with large text and plain wording. Give every month, and have a failed monthly payment retried with the donor told. Pause or stop a monthly gift. Email a receipt for every gift, and offer a yearly giving summary. A campaign page with its goal and how much has been raised so far. Then the items that pull in other directions: volunteer sign-up, shift reminders, and a staff view of the day's gifts and totals.

Every item has an advocate. That is the design. The scenario is not about picking the best feature, but about telling the people who advise from the people who decide, and routing each request to the right place.

Who has a vote

The sponsor is the executive director, who has led the food bank for nine years and has promised the funder a go-live date. She wants everyone to feel heard and finds it hard to say no to the board chair. She relays what people ask for, usually with the words "they would really like".

Around her sit the rest of the team, played by AI unless you take the role.

• The Product Owner coordinates volunteers and writes the newsletter. It is her first time in the role, and she finds it hard to disappoint people she works alongside every week.
• The Scrum Master, when it is not you, asks who decides before he asks how long it will take.
• The lead architect is careful about anything touching money and will not call a payment page done without limits on repeated attempts.
• The frontend developer builds accessible forms first and treats large text and keyboard use as part of the work.
• The backend developer is a volunteer who gives a day some weeks and nothing in others, and wants the team to plan around that, not apologise for it.

Another voice is not on the team at all: the board chair. The sponsor and the Product Owner both mention her, and her wishes reach the project through them.

What is hard about it

Three things, which map to the outcomes on the scenario card.

Advisers and decision-makers look the same. A request from the board chair and a request from the Product Owner arrive in the same polite tone. The scenario asks whether you can tell them apart, and what you do when a senior person who is not accountable for the product pushes. The Product Owner role explains why the Scrum Guide insists that the Product Owner is one person, not a committee.

The date does not move. The card describes the skill as holding a fixed date by trading scope, not quality. When time is short, the temptation is to shave the testing off the payment page. The people who handle money in this scenario have long memories.

Trust is a feature. A product that takes people's money has to look and behave as if it deserves it. Receipts, failed-payment handling, accessible forms and limits on repeated attempts are not decoration.

Phase by phase

Phase 1. Six steps take you from the business case and the donor survey to a release plan. The second step asks you to confirm the roles and a draft of who signs off what. In the workshop on epics and personas, the board's wishes meet the budget.

The workshop leaves a ratified list of large areas of work, each with a value and a risk, that becomes the scope record the later steps refer to.

Phase 2. You check the draft stories, run planning poker with the developers, break the work into tasks and freeze the sprint backlog. With a volunteer developer whose hours change with his on-call rota, capacity is a real question and not a formality.

Phases 3 and 4. Each sprint has its blockers, risks and mid-sprint requests, and at each review you decide what meets the Definition of Done. Our post on stakeholders covers who the people around a team are and how they should take part.

Phase 5. A cutover, an agreement on the working deliverables and a retrospective on the whole project, ending with a scorecard built from the decisions you recorded. It is a scorecard and not a certificate.

Questions to carry into it

Some prompts to keep beside you while you play. None has a hidden answer.

• Who is accountable for this decision? Not who cares most about it, but who answers for the outcome. The Scrum Guide gives the backlog to one person.
• Is this an opinion or an instruction? Relayed requests often arrive with the words "they would really like". Listen for what the person making it is actually asking.
• What does a donor need to trust this page? A donor deciding whether to give is a very different user from a staff member checking totals.
• What does the volunteer developer's calendar say? Planning around a person's real hours is respectful and it is also simply accurate.

The scenario takes place in a kind and well-meaning organisation. That is what makes it hard, because nobody in it is easy to say no to. Pay attention to how you say it, too. A refusal that comes with a reason, and a place where the request will be considered, keeps the relationship intact and keeps the next request coming to the right person. That habit is worth building before you meet a board chair in real life, and a simulated one is a forgiving place to start.

Who it suits

The card says it is for learners ready for many voices and one deadline, and recommends playing Fitness App first. The active work is estimated at about three hours and fifteen minutes, spread over many days.

What each role takes from it:

• Scrum Master: facilitating a team that is pulled in several directions, and asking who decides.
• Product Owner: holding an ordering when several people with good reasons disagree.
• Developer: saying what you cannot reach, and building the parts people will trust.

The other scenarios are described in the scenarios at a glance. Donation Portal is fictional, as are the food bank, its people and the figures. Nothing in it describes a real organisation.