Planning Activities

Planning activities are designed to help you figure out your timeline and deliverables. They work best if combined with requirements and design. Be transparent about things you don’t know yet (risks) and how you will get those answers.

“Plans are worthless, but planning is everything.” – Dwight D. Eisenhower, National Defense Executive Reserve Conference, 1957

Planning and Prioritization guideThe prioritization methods (MoSCoW, the three matrices, Scrum ordering, MIT) and the success-metric frameworks (PMF, AARRR, HEART) explained.

Identify Success Metrics

Team Activity Workshop

Decide what “it worked” will mean, in numbers, while you are still far enough from the deadline to be honest about it. One to two hours as a team, first in winter before your Definition of Shipped and again in the spring workshop, when you write your Definition of Shipped.

Every project commits to 2 or 3 metrics, and what makes a good one differs by outcome type, so start with your own subsection below. Product and game teams can borrow from the PMF question, AARRR, and HEART in the guide.

Four rules hold whatever you build:

Write the metric and the decision rule together: which value is success, which is failure, and what you do in each case.
Commit it, dated, before you measure. Choosing the metric after seeing results is how honest people mislead themselves.
Name the instrument: analytics (Plausible, Google Analytics, Hotjar), database counts, benchmark output, interviews, surveys.
Beware vanity metrics. Downloads mean nothing if nobody comes back. Ask what number would make your partner call it a success.

New Product or Game

Usage and retention are the point, so measure people, not code:

Downloads or sign-ups, monthly active users, churn rate
Average session duration, task success rate
Net Promoter Score, positive mentions or up-votes

AARRR’s activation and retention and HEART’s task success are the usual picks; ProductPlan’s metrics list has more.

Research

Your metric decides what counts as a result, so it is a one-way door: change it late and every earlier run stops being comparable.

The primary metric, and why it is right for the question rather than easiest to compute.
The comparison: against which baseline, on which data split, over how many runs, with which seeds.
The decision rule: what value supports the hypothesis, what value refutes it.
Secondary metrics you will report regardless of outcome, including the ones that could make you look bad.

Pair this with Reproduce Your Baseline; a metric only means something next to a number you have reproduced.

FOSS

Your success is measured in someone else’s repository, so read what the project itself tracks:

Patches submitted, reviewed, merged, and still merged a month later
Review turnaround, and whether maintainers start assigning you work
Issues closed, and whether your changes appear in a tagged release

A trivial patch merged in fall is a stronger signal than a large one unmerged in spring; it proves the pipeline works.

Consultancy

Your top rungs describe actions the partner takes, so measure their adoption rather than your output:

Is it running in their environment, and whose environment is it
How many of their people use it, and for what task
Has it cleared their security or IT review, and when
What would have to be true for them to call it production

In the workshop’s second half, produce the same metrics list with an AI agent (a skill or a structured prompt) and set it beside yours; the differences are the lesson, and either version can be the one you keep.

A good output is 2 or 3 metrics with their decision rules and a named instrumentation method for at least one, committed and dated.

Feeds: the Definition of Shipped metrics-and-instrumentation criterion, and the spring Release and Metrics evidence.

Weekly Work Intensity

Individual Activity

Rate each week of the term as low, medium, or high based on the effort you expect to dedicate to your project, considering other (course) commitments. Throughout the term, track your actual effort and compare it to your predictions. At the end, reflect on how your expectations matched your experience and identify any adjustments needed to better manage your time going forward.

Discuss your weekly work intensity with your team and align expectations.

A good output is your predicted intensity per week next to your actual tracked effort, with a short reflection on the gap.

Plan Prototype

Team Activity Recommended

Your project might have a lot of unknowns, either on the technical feasibility side or on the user side (value or usability).

Here are common feasibility concerns:

Algorithm concerns
Performance concerns
Scalability concerns
Fault tolerance concerns
Use of a technology the team has not used before
Use of a third-party component or service the team has not used before
Use of a legacy system the team has not used before
Dependency on new or related changes by other teams

The idea with a feasibility prototype is to write code, quick and dirty, generally, to tackle items listed above. You could for example build a basic app in a language you have never used before, compare different algorithms on a subset of data, or make sure you can compile legacy code. This code is most likely intended to be thrown away.

On the user side, low-fidelity prototypes are interactive wireframes that only focus on the information and workflow of your software, not the visual design nor differences in the actual data. High-fidelity prototypes are very similar but you’d have to look closer to figure out they’re fake. The visual design and data are very realistic, but the data is not live. Consider Figma for your interactive use prototypes; you can also use pen and paper, PowerPoint, or anything else you feel comfortable with.

Finally, there’s the live-data prototype. Consider it a substantially smaller implementation of the eventual product. The quality, performance, and functionality are very limited, but it runs well enough to collect data for specific use cases. This is the type of prototype you can start iterating on, so figure out feasibility first.

A good output is a plan with the types of prototypes you will build, in what order, and in what time frame, indicating which concerns each one tackles.

Feeds: the fall week 10 repo checkpoint term gate.

Gantt Chart

Team Activity

A Gantt chart is a visual project management tool that displays tasks and timelines. It consists of a horizontal bar chart, where each bar represents a task, showing its start date, duration, and end date. The chart helps in tracking project progress, managing deadlines, and identifying dependencies between tasks, making it easier to plan and monitor the project’s workflow.

For this activity, define your tasks, set the timeline (for all three terms), and create a readable Gantt chart. You could use the Roadmap view on GitHub Projects for that purpose.

Revisit the chart at mid-term and at the end of the term, and reflect on how well you adhered to your plan and any changes made along the way.

A good output is a Gantt chart showing tasks, durations, and dependencies, with the critical path visible.

Dependency Mapping or Critical Path Analysis

Individual Activity Team Activity Workshop

Map task dependencies and identify the critical path to ensure efficient project scheduling and resource management.

List Tasks: Break down the project into individual tasks or activities.
Identify Dependencies: Determine which tasks rely on the completion of others before they can start.
Create a Critical Path Diagram: Map out the sequence of dependent tasks and identify the longest path (critical path) that determines the project timeline.
Analyze and Adjust: Identify potential bottlenecks and adjust timelines accordingly.

In the workshop’s second half, produce the same critical path with an AI agent (a skill or a structured prompt) and set it beside yours; the differences are the lesson, and either version can be the one you keep.

A good output is a dependency map and critical path analysis, including identified bottlenecks and adjustments.

Feeds: the Definition of Shipped prerequisites-and-lead-times criterion, which teams most often underestimate.

Prioritization

Team Activity Recommended

Turn your backlog of requirements or tasks into a ranked list with a reason next to each rank, so that sprint planning pulls from the top instead of re-arguing the order. Forty-five minutes as a team, then a few minutes after every project partner meeting.

Pick one method from the guide: MoSCoW for a first pass, impact-effort or cost-value when the argument is about return on time, Eisenhower for tasks rather than features.
Estimate before you plot: put a rough effort in hours on each item first, or the matrix becomes a vote on enthusiasm.
Apply it to the whole backlog: every item gets a bucket or a quadrant, including the ones you would rather not discuss.
Check dependencies: an item is only ready when nothing above it blocks it. Move blocked items down.
Write the reason: one line per item explaining its rank, readable by a teammate who was not in the room.

A good output is your prioritized list of requirements or tasks, the method you used named, and a stated reason for each item’s rank.

Feeds: the sprint note top-risk-and-decision item.

Risk Management Plan

Individual Activity Recommended

Develop a risk management plan to identify and mitigate potential project risks.

Identify Risks: Consider the Rumsfeld matrix to figure out if you need to do more research or have discussions to uncover additional risk factors.
Assess Impact and Probability: Evaluate each risk’s potential impact on the project and its likelihood of occurring.
Develop Mitigation Strategies: Create contingency plans to address each risk, minimizing its impact.
Monitor and Review: Establish a system for tracking risks and updating the plan as the project progresses.

A good output is a risk management plan detailing risks, their categorization (impact/likelihood), and mitigation strategies. The external-world risks you surface here (approvals, reviews, recruitment) belong in your Definition of Shipped prerequisites.

Feeds: the repo checkpoint decision-and-risk-hygiene criterion.

SWOT Analysis

Individual Activity

Conduct a SWOT (Strengths, Weaknesses, Opportunities, Threats) analysis to identify key internal and external factors affecting your project.

Strengths: Identify the internal strengths of your project (e.g., team skills, resources).
Weaknesses: Determine internal weaknesses (e.g., limitations in knowledge, budget).
Opportunities: Explore external opportunities that could benefit your project (e.g., new technologies, partnerships).
Threats: Identify external risks or challenges (e.g., competitors, regulatory issues).

Write up the SWOT analysis and how these factors will influence project planning and decisions. Consider creating a matrix with four quadrants.

A good output is a completed SWOT grid with at least one concrete action drawn from it.

Kanban Board Setup

Individual Activity Recommended

Set up a Kanban board to visualize and manage your project’s workflow effectively.

Create Columns: Set up key stages like “To Do,” “In Progress,” and “Done” (or project-specific stages).
List Tasks: Break down the project into individual tasks or user stories and add them to the “To Do” column.
Manage Workflow: Move tasks across columns as work progresses to visualize progress.
Limit Work in Progress (WIP): Set WIP limits to avoid overloading team members.
Team Agreement: Discuss the process and tool with your team and ensure everyone agrees.

A good output is your live Kanban board and a brief explanation of its structure. A well-kept board makes writing your Sprint Notes almost mechanical.

Feeds: the repo checkpoint term gate, and every sprint note after it.

Responsibility Assignment Matrix (RACI)

Team Activity Recommended

A RACI matrix is a project management tool that clarifies roles and responsibilities for tasks or deliverables. RACI stands for:

Responsible: The person(s) who perform the work to complete the task.
Accountable: The person who is ultimately answerable for the task’s completion and approves the work.
Consulted: Individuals who provide input or expertise during the task.
Informed: Individuals who need to be kept updated on the task’s progress or completion.

Here’s an example of a RACI matrix:

Task/Deliverable	Team Member A	Team Member B	…	TA/Instructor	Project Partner
Stakeholder Interview	R	A		C	I
Figma: User Login	R	C		I	I
Compare Databases Technology		R		I	C
Testing	R	R	R	I	A

A good output is a RACI matrix for your project, detailing roles and responsibilities for key tasks or deliverables.

Feeds: the Team Charter roles criterion.

Stakeholder Mapping

Individual Activity Recommended

Identify and categorize project stakeholders to ensure effective communication and alignment of expectations.

List Stakeholders: Identify all individuals or groups with a vested interest in the project (e.g., project partners, team members, end users).
Categorize Stakeholders: Use a power-interest matrix to categorize stakeholders based on their influence and interest in the project.
Define Communication Strategies: Establish how and when to communicate with each stakeholder category (e.g., regular updates, feedback sessions).
Review and Update: Regularly reassess the stakeholder map as the project evolves.

A good output is a stakeholder map and a plan outlining communication strategies for each group.

Feeds: the Definition of Shipped prerequisites criterion, and the RFC constraints criterion.

Definition of Done

Individual Activity Recommended

The Definition of Done (DoD) establishes clear criteria for when tasks, features, or the overall project can be considered complete.

List Completion Criteria: Define specific conditions that must be met for each task or feature to be marked as “done” (e.g., all tests passed, documentation updated, code reviewed).
Include Quality Standards: Ensure the criteria cover quality aspects like performance benchmarks, usability, or security.
Team Agreement: Discuss the definition with your team and ensure everyone agrees.

A good output is a short document outlining the agreed-upon Definition of Done for your project. It is the task-level sibling of the project-level Definition of Shipped you write in winter; practicing on tasks makes the project-level version much easier.

Feeds: the repo checkpoint build-health criterion, and every sprint note after it.

How Might We Questions

Individual Activity

The “How Might We” (HMW) technique is a creative problem-framing method used to turn challenges or observations into opportunities for innovation. By rephrasing problems as open-ended questions starting with “How might we…”, you encourage brainstorming and solution-oriented thinking.

Identify a key challenge, pain point, or opportunity area in your project.
Reframe it as one or more “How might we…” questions.
Use these questions to guide ideation sessions or team discussions.

A good output is a list of at least three “How might we…” questions relevant to your project, along with a brief explanation of the challenge each question addresses.

Fishbone Diagram

Individual Activity Recommended

A Fishbone Diagram (also known as an Ishikawa or Cause-and-Effect Diagram) is a visual tool for identifying, exploring, and displaying the possible causes of a specific problem or effect. It helps teams systematically analyze root causes rather than just symptoms.

Clearly define the problem or effect you want to analyze.
Draw the main “spine” (horizontal line) with the problem at the “head.”
Identify major categories of causes (e.g., People, Process, Tools, Environment) and draw “bones” branching off the spine.
Brainstorm and list possible causes under each category.

A good output is a completed Fishbone Diagram (hand-drawn or created with a diagramming tool) for a key problem in your project, along with a short summary of the main causes identified. This is also a useful tool when analyzing root causes for your Incident Postmortem.

Feeds: the Incident Postmortem root-cause criterion, and the repo checkpoint risk hygiene.

Software Release and Versioning

Individual Activity Recommended

Plan the release process for your software, including version control and deployment strategies.

Define Release Process: Outline steps for preparing the software for release (e.g., final testing, documentation updates, packaging).
Establish Versioning Scheme: Choose a versioning system (e.g., Semantic Versioning) to track software updates (e.g., 1.0.0 for major releases, 1.0.1 for patches).
Plan Deployment: Identify how and where the software will be deployed or accessed (e.g., cloud platform, local servers, GitHub repository assets).
Team Agreement: Discuss the process with your team and ensure everyone agrees.

A good output is a release plan document that includes versioning details and deployment steps. It prepares you for the spring Release and Metrics assignment, and the Shipping guide lists the lead times your release path involves.

Feeds: the fall week 10 repo checkpoint term gate, and the spring Release and Metrics.

Software Development Process

Individual Activity

Define and plan the software development process for your project to ensure clear workflow and task management.

Choose a Development Methodology: Select an approach (e.g., Agile, Waterfall, SCRUM) that fits your project.
Outline Development Phases: Break down the process into phases such as planning, design, implementation, testing, and deployment.
Set Milestones: Establish key milestones and goals for each phase.
Assign Roles: Clarify team roles and responsibilities at each stage.
Team Agreement: Discuss the process with your team and ensure everyone agrees.

A good output is a document outlining the chosen process, phases, milestones, and team roles. Much of this belongs in your Team Charter.

Map Your External Approvals

Team Activity Recommended

Find every approval your project needs from someone outside your team, and start the slowest one this week. Ninety minutes in fall weeks 1 to 2, then a standing agenda item.

Research and consultancy projects fail on calendars far more often than on code. IRB review takes weeks even for an exempt determination, data use agreements between institutions can take a full term, and an enterprise security review is measured in months. None of those clocks run faster because you started late.

Ask directly in your first partner or faculty meeting: what approvals does this project need, who files them, and how long do they usually take?
List every clock: IRB or human-subjects review, data use agreements, security or IT review, vendor onboarding, account provisioning, CLA signing for FOSS, license review, export control.
For each, record who owns it, when it starts, how long it historically takes, and what is blocked until it lands.
Start the longest one now, even from an incomplete application, if the process allows amendment later.
Put them in docs/risks.md with owners and dates, and review them at every checkpoint.

A good output is a dated table of every external approval with an owner and an expected duration, living in your risk register, with the longest clock already started.

Feeds: the repo checkpoint decision-and-risk-hygiene criterion, and the Definition of Shipped prerequisites-and-lead-times criterion.