Software engineering templates, page 2

Software engineering templates 61–89 of 89

• 

  Eval review board

  Go through test cases for an AI feature: the input, what good looks like, what it actually said and the verdict.

• 

  Ready and done checklists

  Agree what an item needs before the team starts it, and what has to be true before anyone calls it done.

• 

  Rules and examples

  Before building a story, agree its rules and a concrete example for each, and collect the questions nobody can answer yet.

• 

  Cycle time review

  Look at how long work really took from start to finish, where it waited, and what would make it flow faster.

• 

  Analysis plan

  Plan a piece of analysis before touching the data: the question, what answer would change a decision, the data, the method and the risks.

• 

  Model card

  Describe a machine learning model for the people who rely on it: what it does, its data, how well it works, for whom, and its limits.

• 

  Analytics tracking plan

  Decide which user actions a feature records before it is built: the event names, what each carries and the question it answers.

• 

  Design system audit

  Inventory how a component is really used across the product, the inconsistencies you found and what to do about each one.

• 

  Accessibility review

  Review a screen or flow against the four public principles of accessible design, with concrete checks and what to fix.

• 

  Build, buy or partner

  Compare building a capability yourself, buying it, or partnering for it, on cost, speed, control and risk.

• 

  Feature sunset review

  Decide whether to retire a feature: who still uses it, what it costs to keep, what replaces it and how to tell people.

• 

  Metric definitions

  One agreed definition per product metric: what it counts, how it’s calculated, its target, owner and where the data comes from.

• 

  Design QA checklist

  Check a built feature against the design before release: layout, states, content, accessibility and responsiveness.

• 

  Component proposal

  Propose a new design system component: the need, where it’s used, its variants and states, accessibility and what it replaces.

• 

  Morphological box

  Split a design problem into its parameters, list the options for each, then combine one option per row into whole concepts.

• 

  Hackathon plan

  Plan an internal hackathon from theme to demos: dates, teams, rules, judging and what happens to the winning projects afterwards.

• 

  Hackathon project pitch

  One page for a hackathon team: the problem, who has it, what you will build in the time, the demo you will show and who you need.

• 

  Value stream map

  Follow one request through every step to delivery, with work time and wait time at each, to see where time really goes.

• 

  Failure modes review

  Go step by step through a process and ask how each step could fail, how bad it would be, how likely, and how you’d catch it.

• 

  Escalation matrix

  Who to call, how fast, at each severity level: so nobody wonders at 2am whether to wake someone up.

• 

  Records of processing

  Keep a record of each activity that uses personal data: what data, why, on what basis, who it is shared with and how long it is kept.

• 

  Privacy impact assessment

  Before a new project uses personal data, think through what it collects, the risks to the people involved and how to reduce them.

• 

  Vendor security review

  Check a supplier before they get your data or systems: what they will access, how they protect it and what the contract must say.

• 

  Data retention schedule

  Decide how long each kind of record is kept, why, where it lives and what happens to it at the end, then check that it happens.

• 

  Pre-mortem

  Imagine the project has already failed, list every reason why, then decide what to do now so it doesn’t.

• 

  Five whys

  Ask "why?" until you reach a cause you can actually fix, writing down the evidence for each answer on the way.

• 

  Requirements traceability

  Trace each requirement to the design that meets it, the test that proves it and its status, so nothing agreed is forgotten at sign-off.

• 

  Straw, sticks, bricks retro

  Sort the team’s practices by how sturdy they are: flimsy ones that fall over, shaky ones that need work, solid ones to build on.

• 

  Release retrospective

  Look back at one release: what we planned against what shipped, quality signals, how the hand-offs went and what changes next time.