You leave with: answers to the six questions below, written in your own words — plus enough vocabulary to sit in a refinement, a sprint planning and a retrospective and know what each one is for. No code. Nothing here assumes you have ever opened an editor.
Every definition, number and quotation in this workshop comes from one source: Atlassian’s Agile Coach. That is deliberate. Agile has twenty-five years of argument attached to it, and the fastest way to make a newcomer feel stupid is to hand them four books that disagree with each other. One source, quoted directly, so you can go and read the whole thing afterwards and recognise where you have been.
Before we startSix questions you probably cannot answer yet
Read them now. Do not look anything up. Do not worry about being wrong — being wrong at 09:15 is the entire point of the exercise. Write an answer to each one anyway, one line each, and keep the paper.
We come back to this list at the end. The measure of whether this workshop worked is not whether you enjoyed it. It is whether your six answers at 13:00 are better than your six answers at 09:15.
“Agile means working in two-week sprints with a daily stand-up.” True or false — and what is your reasoning?
The Agile Manifesto says working software over comprehensive documentation. So does an agile team write documentation, or not?
What is the difference between Agile and Scrum? Are they two names for one thing?
Who decides what the team builds next — and who decides how much of it fits into one sprint? The same person, or two different people?
At what point in the process does testing start?
A stand-up runs forty minutes and each person reports their progress to the manager. Name everything that is wrong with that sentence.
Facilitator: collect the sheets and do not discuss the answers now — not even the ones that are obviously right. The disagreement is the content, and it is worth far more at the end, when the room can settle it themselves.
What agile actually is
Start with the definition, because nearly everything people believe about agile is an accretion on top of it rather than the thing itself.
“The Agile methodology is an approach that divides work into phases, emphasizing continuous delivery and improvement. Agile benefits teams by enabling adaptive planning, rapid execution, and ongoing evaluation, leading to more responsive and successful outcomes.”
Notice what is not in that sentence. No sprints. No stand-ups. No story points, no burndown chart, no board. Atlassian says so outright, and this is the single most useful correction in the whole workshop:
“The original Agile Manifesto didn’t prescribe two-week iterations or an ideal team size. It laid out a set of core values that put people first.” And: “Agile isn’t defined by a set of ceremonies or specific development techniques.”
So when somebody says “we are doing agile” and means “we have a two-week sprint and a stand-up at 09:30”, they have named two practices and zero principles. The practices are downstream, and they are negotiable. Atlassian is candid that there is no house method even inside their own company: “No two teams inside Atlassian have identical workflows… we’re not strict followers of any single methodology.”
If you want a memory hook, the root page offers the 5 C’s — “Communication, Collaboration, Commitment, Customer, Continuous Improvement” — with four common frameworks underneath: “Scrum, Kanban, Lean, and Extreme Programming (XP).”
Foundations · 2Snowbird, 68 words, and the four values
In early 2001, seventeen people met at a ski resort in Snowbird, Utah. What came out was 68 words. The problem they were reacting to is one you will recognise immediately:
“The problem, they agreed, was that companies were so focused on excessively planning and documenting their software development cycles that they lost sight of what really mattered—pleasing their customers.”
The four values, verbatim:
| We value this… | …over this |
|---|---|
| Individuals and interactions | processes and tools |
| Working software | comprehensive documentation |
| Customer collaboration | contract negotiation |
| Responding to change | following a plan |
And then the line printed directly underneath them in the original, which almost everyone forgets:
“That is, while there is value in the items on the right, we value the items on the left more.”
This is a preference ordering, not a prohibition. Agile does not say “write no documentation”, “have no process” or “do not plan”. It says that when the two are genuinely in tension — when you can either ship the thing or finish the document describing the thing — you ship. That is question 2, answered.
The twelve principles are the Manifesto’s other half. Atlassian references them without listing them, summarising their themes as “customer satisfaction, embracing change, frequent delivery, collaboration, motivated teams, face-to-face conversation, working software, sustainable pace, technical excellence, simplicity, self-organizing teams, and regular reflection for improvement.”
“Faux agile” has a name. Ron Jeffries, one of the seventeen, uses a quoted “Agile” for “the many instances, approaches, and processes that use the word ‘agile’ to describe themselves, but that do not necessarily adhere to the letter or spirit of Agile Software Development we wrote about in the Agile Manifesto.” If this workshop gives you one piece of licence, take this one: a practice that is making your team worse is not made correct by being called agile.
Agile is not Scrum. Scrum is one way to do agile
This is question 3, and it is the confusion that costs new teams the most time.
“Agile is a set of principles for iterative and collaborative software development, while Scrum is a specific framework that implements Agile values through defined roles, events, and artifacts. In other words, Scrum is one way to practice Agile, but not the only way.”
The practical difference is how much each one tells you to do: “Agile doesn’t have any set rules, while scrum has quite a few!” Agile is the direction. Scrum is one route, with named roles, named meetings and named artefacts. Kanban is a different route; Lean and XP are others.
One more contrast, for anyone who has only ever worked on a fixed-scope project:
Waterfall
“the scope of a product is set and time and resources are flexible.” You know exactly what you are building, and you discover late what it costs.
Agile
“the scope of the product is flexible while resources and time are fixed.” You know what you can spend, and you decide repeatedly what to spend it on.
That inversion is why a product owner exists at all. If scope is the flexible variable, somebody has to keep choosing — every sprint, forever. That is the job.
The frameworks · 4Scrum, in one page
“Scrum is an Agile project management framework that helps teams organize and oversee their work through values, principles, and practices. Scrum encourages teams to learn through experience, self-organize while working on a problem, and reflect on their successes and failures to continuously improve.”
Atlassian gives a scaffold worth memorising — the 3:5:3 rule: “3 roles (Product Owner, Scrum Master, Development Team), 5 events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), and 3 artifacts (Product Backlog, Sprint Backlog, Increment).”
The five Scrum values are “Commitment, Courage, Focus, Openness, Respect.” Sprints “typically last from one to four weeks”, and “Two weeks is a typical sprint length.”
Three corrections that matter more to this room than any of the above:
-
The roles are not job titlesEveryone
“The three scrum roles describe the key responsibilities for those on the scrum team. They aren’t job titles.” On whether you must rename people when you adopt Scrum: “Many teams ask if they need to change their titles when adopting scrum. The short answer is no.”
-
There is one product owner, and it is a personPO
“The product owner must be an individual. No development team wants mixed guidance from multiple product owners.” Worth saying out loud too: “The product owner is not always the product manager.”
-
Nobody manages the teamTeam
“A Scrum team does not have a traditional leader; instead, leadership is distributed among the roles.” Put more bluntly elsewhere: “Who manages the scrum team? Well, nobody. Scrum teams are self-organizing and everyone is equal, despite having different responsibilities.”
The Scrum Master is “the facilitator of scrum… coaches to the rest of the team, or servant leaders, as the Scrum Guide puts it”. The point of the role is the opposite of control: “The best scrum teams are self-organizing and, therefore, don’t react well to micromanagement.”
Half-Scrum does not work. “Scrum is an ‘all-in’ approach… When teams fail to go ‘all-in’ they often fail to unlock the benefits of scrum… Eventually, you’re back to doing waterfall!” If you are going to try it, the advice is concrete: “We advise using all the ceremonies for two sprints and seeing how it feels.”
Kanban, and how to choose
“Kanban is a visual workflow management method that allows teams to optimize and continuously improve the delivery of work by visualizing tasks, limiting work in progress, and focusing on flow efficiency.”
Its four principles: “visualize the workflow, limit work in progress, manage flow, and continuously improve.” It came out of Toyota in the late 1940s, modelled on supermarkets — “where shelves are restocked based on what customers actually use.”
The one idea to take from Kanban even if your team runs Scrum is the WIP limit, because it is counter-intuitive and it is measurable:
“Taking on too much work at once can hurt efficiency. When teams take on too much at the same time, context switching increases and tasks take longer to complete.” The worked example: four states — To Do, In Progress, Code Review, Done — and “a WIP limit of 2 for the code review state.”
Side by side, in Atlassian’s own table:
| Scrum | Kanban | |
|---|---|---|
| Origin | Software development | Lean manufacturing |
| Cadence | Regular, fixed-length sprints (i.e. two weeks) | Continuous flow |
| Practices | Sprint planning, sprint, daily scrum, sprint review, sprint retrospective | Visualize the flow of work, limit work-in-progress, manage flow, incorporate feedback loops |
| Roles | Product owner, scrum master, development team | No required roles |
And the answer to “so which do we pick”, which is less dramatic than people expect:
“It’s easy to point out the differences between scrum practices and kanban practices, but that’s just at the surface level. While the practices differ, the principles are largely the same.” And: “Your decision doesn’t need to be so black and white. Hundreds of teams are using hybrid models influenced by both scrum and kanban.”
The backlog: one list, in order
“A product backlog is a prioritized list of work for the development team that is derived from the product roadmap and its requirements. The most important items are shown at the top of the product backlog so the team knows what to deliver first.”
Two rules about it are worth more than the definition. The first is that everything goes in one list: “All work items should be included in the backlog: user stories, bugs, design changes, technical debt, customer requests, action items from the retrospective, etc.” And: “It’s best to keep everything in one issue tracker. Don’t use multiple systems to track bugs, requirements, and engineering work items.”
For a QA reader that sentence has teeth. A bug is a backlog item, competing on the same list as a feature, ordered by the same person — not a separate queue with its own rules.
The second rule is pull, not push, and it is the one new product owners find hardest:
“The development team doesn’t work through the backlog at the product owner’s pace. Also, the product owner isn’t pushing work to the development team. Instead, the development team pulls work from the product backlog as there is capacity for it, either continually (Kanban) or by iteration (Scrum).”
Which gives the cleanest statement of the split in the whole source: “Let product owners dictate the priority of work items in the backlog, while the development team owns its velocity. This can be a tenuous relationship for new product owners who want to ‘push’ work to the team.” That is question 4, answered: two different people, and neither can do the other’s half.
What moves an item up the list: “Customer priority”, “Urgency of getting feedback”, “Relative implementation difficulty”, and “Symbiotic relationships between work items (e.g. B is easier if we do A first)”. Named frameworks: “MoSCoW (Must-have, Should-have, Could-have, and Won’t-have) or weighted scoring”.
Three anti-patterns, listed as such on the page:
| Anti-pattern | What it looks like on a real team |
|---|---|
| “The product owner prioritizes the backlog at the start of the project but doesn’t adjust it as feedback rolls in” | The order was set in January and nobody has touched it since. |
| “The team limits items on the backlog to those that are customer-facing” | Technical debt and test automation are invisible, so they never get done. |
| “The backlog is kept as a document stored locally and shared infrequently” | A spreadsheet on somebody’s laptop. Nobody else can see the order. |
Stories, epics, initiatives
“A user story is the smallest unit of work in an Agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.”
The template: “As a [persona], I [want to], [so that].” Each third does a specific job:
-
As a [persona]Who
“Who are we building this for? We’re not just after a job title, we’re after the persona of the person.”
-
I want to…What
“Here we’re describing their intent — not the features they use… This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you’re missing the point.”
-
So that…Why
“how does their immediate desire to do something this fit into their bigger picture?”
A worked example from the page: “As a shopper, I want to save items to a wishlist so that I can purchase them later.”
The mnemonic Atlassian teaches here is the 3 C’s: “Card, Conversation, and Confirmation. The Card represents the written description of the story, Conversation refers to the discussions that clarify details, and Confirmation is the acceptance criteria that define when the story is complete.” The story is not the whole requirement — it is the promise of a conversation, plus the test that ends it.
A story is not a specification. “It’s tempting to think that user stories are, simply put, software system requirements. But they’re not… They don’t go into detail. Requirements are added later, once agreed upon by the team.” For QA, the operative line is the next one: “Including acceptance criteria helps teams understand what success looks like and ensures that the story is testable.”
Above the story sit two larger containers, and the boundary between story and epic is a duration, not a topic:
| Level | Definition | How long |
|---|---|---|
| Story | “short requirements or requests written from the perspective of an end user” | “something the team can commit to finish within a one- or two-week sprint” |
| Epic | “large bodies of work that can be broken down into a number of smaller tasks (called stories)” | “two or three epics… each quarter” |
| Initiative | “collections of epics that drive toward a common goal” | “multiple quarters to a year” |
The rule that settles most arguments: “any scope of work that the team estimates at ‘weeks’ (or longer) to complete, rather than ‘hours’ or ‘days’ should be considered an epic and broken down into smaller stories.” And you do not have to force everything into a hierarchy — “Not every user story needs to be part of an epic; some stories are small enough to stand alone and deliver value independently.”
A theme, incidentally, is defined only once across these pages: “A theme is an organization goal that drive the creation of epics and initiatives.”
Finally, a line to keep for your next stakeholder meeting: “If you were reporting your team’s progress to the Head of Engineering, you’d be speaking in epics. On the other hand, if you were talking to a colleague on your development team, you’d speak at the story level.”
The work · 8Estimating in points, not days
“A story point is a unit of measure used in Agile estimation to express the relative effort required to complete a user story or task. Story points consider complexity, risk, and the amount of work, rather than specific hours or days.”
Why not just say “three days”? Because a day is not three days of work:
-
Days are dishonestReality
“Dates don’t account for the non-project related work that inevitably creeps into our days: emails, meetings, and interviews…”
-
Days are emotionalPeople
“Dates have an emotional attachment to them. Relative estimation removes the emotional attachment.”
-
Points cannot be weaponised across teamsPolitics
“Each team will estimate work on a slightly different scale, which means their velocity (measured in points) will naturally be different. This, in turn, makes it impossible to play politics using velocity as a weapon.”
The hard number: “No individual task should be more than 16 hours of work. (If you’re using story points, you may decide that, say, 20 points is the upper limit.)… When something is estimated above your team’s 16-hour (or 20-point) threshold, that’s a signal to break it down into more granular pieces and re-estimate.”
Estimating is done together, by hand, with cards — planning poker: “each member will mentally formulate an estimate. Then everyone holds up a card with the number that reflects their estimate. If everyone is in agreement, great! If not, take some time (but not too much time–just couple minutes) to understand the rationale behind different estimates.” The disagreement is the information; the number is a by-product.
QA belongs in that room, explicitly. “Involving everyone (developers, designers, testers, deployers... everyone) on the team is key… if product management wants to do something that seems simple, like support a new web browser, development and QA need to weigh in because their experience has taught them what dragons may be lurking beneath the surface.” Leaving them out “creates lower quality estimates, lowers morale because key contributors don’t feel included, and compromises the quality of the software.”
How points go wrong: “Story points go wrong when they’re used to judge people, assign detailed timelines and resources, and when they’re mistaken for a measure of productivity.” And the line to quote when someone treats an estimate as a promise: “Agile story points estimation is just that: an estimate. Not a blood-oath.”
The four ceremonies, and what each is for
“Scrum ceremonies are events where the scrum master, product owner, and development team meet to plan work, discuss work in progress, gather feedback, and more.” “The four main Scrum ceremonies are sprint planning, daily stand-up (daily scrum), sprint review, and sprint retrospective.”
| Ceremony | When | Length | What it is for |
|---|---|---|---|
| Sprint planning | Start of the sprint | “no more than two hours for each week of the sprint” | “defines what can be delivered in the upcoming sprint and how that work will be achieved” |
| Daily stand-up | Every day | “no more than 15 minutes” | “a short, daily meeting to discuss progress and identify blockers” |
| Sprint review | End of the sprint, before the retro | “30 minutes to an hour for each iteration” | Demo the increment and collect feedback. Outward-facing, with stakeholders. |
| Retrospective | After the review | “typically 45 minutes per week of iteration” | “what went well, what could be improved, and how to make positive changes”. Internal. |
Atlassian’s own pages disagree on these numbers — sprint planning is “one hour per week of iteration” on the ceremonies page and “no more than two hours for each week of the sprint” on the planning page; the sprint review is “30 minutes to an hour” in one place and “a maximum of four hours” for a one-month sprint in another. Pick one, write it down, and move on. The rule that resolves it: “A timebox is a maximum time allowed; there is no minimum time allowed.”
Review and retrospective are different meetings, and new teams collapse them: “A sprint review focuses on the product, showcasing completed work and collecting stakeholder feedback, while a retrospective centers on the team’s process… The sprint review is outward-facing, involving stakeholders, whereas the retrospective is an internal team meeting.” Also: “Avoid reviewing unfinished work — as the Agile Manifesto puts it, the goal is working software!” and, for anyone dreading it, “The review isn’t adversarial, it’s not an exam.”
The stand-up asks three questions: “What did I work on yesterday?” / “What am I working on today?” / “What issues are blocking me?” Which brings us to question 6:
“Let’s be real: stand-ups by themselves don’t make your team agile. They aren’t about inflating egos or justifying job descriptions. They aren’t a time to plan; Sprint planning is for planning. They also aren’t the only time to mention blockers. If you’re stuck, ask for help!” Elsewhere: “It’s not a detailed status meeting.”
A retrospective that produces nothing is also a known failure: “Retrospectives aren’t just a time for complaints without action”, and the fix is the fifth step of Atlassian’s own template — after “Create an action plan” comes “Be disciplined about executing #4.”
And the umbrella caution over this whole section: “Some people think agile ceremonies magically make a team agile. They’re wrong. A team’s agility is built on solid engineering practices, a tactical and strategic approach to change, and great team collaboration.”
Refinement: the meeting where your two jobs meet
If you take one meeting away from this workshop, take this one. It is the meeting where a product owner and a QA engineer do their most valuable work together, and it happens before anybody writes code.
“Backlog refinement is the process of reviewing, ranking, and editing your product backlog… an ongoing process championed by the product owner, product managers, scrum master, and representatives from the development team.”
On the vocabulary: “There is no difference between backlog grooming and backlog refinement. While both terms are often used interchangeably, ‘refinement’ emphasizes the iterative improvement of backlog items rather than just cleaning or tidying up.”
Who is in the room — and this is the strongest single sentence in the source for a QA audience:
“Not all team members are required but it’s important to have at least one representative from dev and QA present.” And what each contributes: “developers can highlight technical dependencies, while testers can identify potential risks, ensuring that backlog items are well-prepared for future sprints.”
Elsewhere QA is listed outright as an attendee category: “Quality assurance representatives: This team knows all the bugs and can add insight into what needs immediate attention. QA testers and/or their supervisor are good candidates for this.”
Two acronyms govern the output. DEEP describes a healthy backlog — “Detailed appropriately… Emergent… Estimated… Prioritized” — and DoR, the definition of ready, is the gate: “an agreed-upon set of criteria to indicate whether a backlog item is ready for the team to work on. The DoR ensures the team understands what the work entails and can estimate the time needed for it to get done.”
The practical rules:
| Rule | Source wording |
|---|---|
| Cadence | “Backlog refinement needs to happen before each sprint planning meeting… If sprints are two weeks, the project manager should plan a session every other week.” |
| Length | “aim for hour-long meetings… and the meeting facilitator rigorously timeboxes them” |
| Depth of backlog | “maintain two sprints worth of items in the backlog so the team always has a fresh supply of work” |
| Splitting | “ensuring each backlog item never takes over half a sprint to complete” |
| The 24-hour rule | “the product owner should send out the list of stories they would like to review with the team at least 24 hours before… This allows the team to review the list and prepare questions.” |
Two habits that separate a good refinement from a ritual one. It is also a deletion meeting: “If you ever feel tempted to ‘cancel’ a backlog refinement meeting because there is no new work, consider asking yourself whether there is any work in the backlog that the team should consider removing.” And it is not the only moment refinement happens: “If you only refine backlog items during the refinement meeting, you’ll find backlog refinement to be a drawn-out activity.”
Your seat · 11What a product owner actually owns
“A product owner is a member of an Agile team who focuses on maximizing the value of the product being built. They’re the bridge between stakeholders like executives, customers, and marketing teams, and the development team doing the actual building… this person takes ownership of the backlog and decides which features or improvements get worked on first.”
The five responsibilities, verbatim: “Manages the product backlog… Defines the product vision… Acts as the main point of contact between stakeholders and developers… Makes decisions on scope and priorities to maximize product value… Collaborates with the team to ensure product quality and delivery.”
Against a product manager: “A product manager typically takes a broader view, focusing on market research, competitive analysis, and overall product strategy. A product owner is focused on execution and working directly with the development team to translate vision into specific features and user stories… The product manager sets the direction, and the product owner makes sure the team executes on that direction effectively.”
What the job is not is where new product owners get into trouble. All of these are stated on the pages as things the PO does not do:
| Not the PO’s call | Why |
|---|---|
| How much fits in the sprint | “the development team owns its velocity” |
| The pace of the team | “the product owner isn’t pushing work to the development team” |
| How it gets built | “leave implementation details to the development team” |
| Prioritising alone | “it’s not done in a vacuum. The best product owners seek input and feedback from customers, designers, and the development team.” |
| Writing the requirements alone | “Never write a product requirements document by yourself–you should always have a developer with you and write it together.” |
| Changing scope mid-sprint | Listed as an anti-pattern under every metric: “The product owner adds or changes the scope mid-sprint.” |
And the thing to make peace with early, because it will feel like losing: “Stakeholders will challenge priorities, and that’s good.”
The other half of the role is protective: product owners “field questions from stakeholders about timelines and priorities while protecting the team from too many interruptions.” If you do nothing else well in the first month, do that.
Where QA actually sits
This is question 5, and the honest answer is that the question contains a mistake. Here is the model agile replaces, described on the page as a problem:
“Waterfall project management separates development and testing into two different steps: developers build a feature and then ‘throw it over the wall’ to the quality assurance team (QA) for testing. The QA team writes and executes detailed test plans.” Why it fails: “as the product grows, the amount of testing grows exponentially–and QA invariably struggles to keep up. Project owners face an unwelcome choice: delay the release, or skimp on testing.”
There is a harder sentence still, and it is worth reading aloud because it names an incentive nobody usually says out loud: “To make matters worse, QA teams are traditionally rewarded according to how many bugs they find, which puts developers on the defensive.”
So who owns quality? Not QA alone: “at Atlassian we empower (nay: expect) our developers to be great champions for quality”, and “each user story in the backlog requires both feature code and automated test code… we find it’s more effective to have a single engineer deliver the complete set.”
That sounds, on a first read, like QA being written out. It is the opposite:
“This model doesn’t mean developers work alone. It’s important to have QA engineers on the team as well. QA brings an important perspective to the development of a feature, and good QA engineers know where bugs usually hide and can advise developers on probable ‘gotchas.’”
The work moves from the end of the process to all of it. Four places QA is named as a participant before the code exists:
-
RefinementBefore estimating
“it’s important to have at least one representative from dev and QA present” — “testers can identify potential risks”.
-
EstimationBefore committing
“development and QA need to weigh in because their experience has taught them what dragons may be lurking beneath the surface.”
-
The definition of doneBefore starting
“it is agreed upon by the entire project team, including developers, testers, product owners, and other stakeholders.”
-
Requirements and acceptance criteriaBefore building
“Frequent collaboration with product, design, QA, and operations lowers rework, clarifies acceptance criteria, and helps teams ship what users actually need.”
And during development, the distinctive QA skill is exploratory testing, which is explicitly not manual script-following:
“Exploratory testing is a risk-based, critical thinking approach to testing that enables the person testing to use their knowledge of risks, implementation details, and the customers’ needs… without the need for scripted test cases, detailed test plans, or requirements.” In practice: “QA team members pair with developers in exploratory testing, a valuable practice during development for fending off more serious bugs.”
On the fear that automation makes the role redundant, the source is unusually direct: “Some testers view automated tests as an existential threat. This thinking is short-sighted, and couldn’t be further from the truth. Freed from the drudgery of repetitive testing tasks, testers can spend time on risk analysis, test planning, and building other skills–like learning to code!”
One rule to take back to your desk on Monday, because it converts a bug into a permanent improvement: “If a bug surfaces during development, take the time to understand the mistake, fix it, and move on. If a regression appears (i.e., something worked before but doesn’t anymore), then it’s likely to reappear. Create an automated test to protect against that regression in the future.”
Your seat · 13Done, and how you know
Two artefacts decide whether a piece of work is finished, and product owners and QA blur them constantly.
Definition of done
“a set of criteria that a product increment must meet for the team to consider it complete and ready for customers.” One list, for everything the team ships.
Acceptance criteria
Per story, and specific to it. The “Confirmation” in the 3 C’s — what makes the story testable at all.
“Remember that the definition of done is not the same thing as acceptance criteria… The DoD is a set of activities the team believes need to be completed in order to call the user story ‘done’ (which might include acceptance criteria) but it’s not the same thing as saying the user story was implemented correctly.” The worked contrast: a DoD item is “All documentation is written and updated”; an acceptance criterion is “The link to the user documentation is accessible from the navigation menu.”
A usable definition of done, quoted: “implemented code, tests added and passing, code reviewed, security and quality checks green, documentation updated, and feature toggles or rollout plan defined.” Two rules about writing it: “Don’t be vague (All code tested); be specific (All code thoroughly tested via unit, integration, and end-to-end tests)”, and “Keep it visible… Print it out and hang it on the wall.”
The loop that makes this worth the meeting: “Every bug or error found during a sprint is a quality issue that an unclear definition of done may have caused… Updating the DoD then becomes crucial so the bug does not reoccur.” A bug is evidence about your process, not just about the code. “The definition of done should be a living document” — “Consider reviewing the DoD every quarter.”
Sitting alongside it is the definition of ready, its mirror image: “The DoR defines when a backlog item is ready for a team to work on in an upcoming sprint. A team uses the DoR during the backlog refinement process.” DoR guards the entrance; DoD guards the exit. A product owner should care a great deal about the first and a QA engineer about both.
Finally, the trade-off rule that tells you what agile does when a sprint is going badly: “Agile flexes scope before quality.” If something has to give, it is the amount, not the standard.
Answers · 14The six questions, answered
Get your sheet out. Read your 09:15 answer first, out loud if you are willing, then the answer below. Nobody is scoring this. The only thing that matters is whether you can now say why.
“Agile means two-week sprints and a daily stand-up.”
False. Those are practices from one framework. “The original Agile Manifesto didn’t prescribe two-week iterations or an ideal team size”, and “Agile isn’t defined by a set of ceremonies or specific development techniques.” Agile is a set of values about who you listen to and how quickly you change your mind. A team can run sprints and stand-ups and still not be agile — and a team can be agile without either.
Working software over comprehensive documentation — so do we document?
Yes. The Manifesto’s own next line settles it: “while there is value in the items on the right, we value the items on the left more.” It is a preference ordering for moments of conflict, not a ban. The definition of done even names “documentation updated” as a completion criterion.
Agile versus Scrum.
Not the same thing. “Scrum is one way to practice Agile, but not the only way.” Agile is principles; Scrum is a framework with three roles, five events and three artefacts. Kanban, Lean and XP are alternative routes to the same values. Practically: “Agile doesn’t have any set rules, while scrum has quite a few!”
Who decides what, and who decides how much?
Two different people, and the split is deliberate. “Let product owners dictate the priority of work items in the backlog, while the development team owns its velocity.” The PO orders the list; the team pulls from it at its own pace. “The product owner isn’t pushing work to the development team.”
When does testing start?
Before the code exists — the question assumes a phase that agile removes. Testing as a stage at the end is the waterfall model where developers “throw it over the wall” to QA. In an agile team, QA is named in refinement (“at least one representative from dev and QA present”), in estimation, in writing the definition of done, and in clarifying acceptance criteria — then pairs with developers in exploratory testing while the feature is built. Quality is not a gate; it is a property everyone carries.
The forty-minute stand-up where everyone reports to the manager.
At least four things. The length — “no more than 15 minutes”. The direction — it is a team sync, not a report upward; “It’s not a detailed status meeting” and it is not “about inflating egos or justifying job descriptions”. Probably the content — “They aren’t a time to plan; Sprint planning is for planning.” And the implied manager — “Who manages the scrum team? Well, nobody.” If blockers are being saved for this meeting, that is a fifth: “If you’re stuck, ask for help!”
If your six answers are better than they were this morning, the workshop worked. Not because you memorised Atlassian’s wording, but because you can now argue with it — which is the only honest measure of understanding a process framework.
Facilitator run sheet
Half a day, four hours with breaks, for a room of product owners and QA engineers with no development background. The two question slots are the spine — everything else can be cut for time.
| Time | Min | What happens |
|---|---|---|
| 09:00 | 15 | The six questions. Hand out paper. Everyone writes six one-line answers alone, in silence. Collect the sheets. Do not discuss any of them — the temptation to correct question 1 immediately is strong and it wastes the whole device. |
| 09:15 | 45 | Foundations 1–3. What agile is, Snowbird and the four values, agile vs Scrum. Slow down on “we value the items on the left more”; it is the sentence that changes how people read the other three values. |
| 10:00 | 30 | Frameworks 4–5. Scrum’s 3:5:3 and Kanban’s WIP limit. Ask the room to guess their own team’s WIP before you show the example. |
| 10:30 | 15 | Break. |
| 10:45 | 45 | The work 6–8. Backlog, stories, estimation. Exercise: hand out three real items from your own backlog and have pairs rewrite them as “As a… I want to… so that…”. Most will describe the UI on the first attempt — that is the lesson, so let it happen. |
| 11:30 | 40 | The rhythm 9–10. The four ceremonies and refinement. Exercise: run ten minutes of real refinement on one of the rewritten stories, with the QA people asked explicitly for risks. This is the moment the QA half of the room understands the workshop is about them too. |
| 12:10 | 30 | Your seat 11–13. PO ownership, QA position, done vs ready. Read the “rewarded according to how many bugs they find” line out loud and stop talking for a moment. |
| 12:40 | 20 | The six questions, answered. Hand the sheets back. Go question by question; let the room answer before you reveal. Ask who changed their mind and on which one. |
| 13:00 | — | Close. Each person writes one thing they will do differently next sprint. Collect those too, and read them at the next retrospective. |
Two traps for the facilitator. First: a room with no development background will ask “but what is the right sprint length / team size / meeting duration”. The honest answer is in the source — Atlassian’s own pages give conflicting numbers, and “There’s no right way to scale agile.” Say so; it builds more trust than a confident invented number. Second: do not let the session become a Jira tutorial. The tool is not the subject, and reaching for it is how a workshop about principles turns into a workshop about fields.
Next up. This workshop stops at the vocabulary. Part 0 — Software Development Life Cycle & the way we work takes the same team and walks one real ticket through thirteen board stations, six actors and a green pipeline. Run them in that order; this one is the prerequisite.
Sources, all under
atlassian.com/agile:
/manifesto, /scrum,
/scrum/roles,
/scrum/scrum-master,
/scrum/agile-vs-scrum,
/scrum/sprints,
/scrum/sprint-planning,
/scrum/sprint-reviews,
/scrum/retrospectives,
/scrum/standups,
/scrum/ceremonies,
/scrum/backlogs,
/scrum/backlog-refinement,
/kanban,
/kanban/kanban-vs-scrum,
/project-management,
/project-management/user-stories,
/project-management/epics,
/project-management/epics-stories-themes,
/project-management/estimation,
/project-management/metrics,
/project-management/definition-of-done,
/project-management/backlog-grooming,
/project-management/backlog-refinement-meeting,
/product-management,
/product-management/product-owner,
/product-management/requirements,
/software-development,
/software-development/testing,
/software-development/continuous-integration,
/agile-at-scale.