Team Artifacts
Scrum Team Training — Working Agreements · User Stories · DoR · DoD
Working Agreements
User Stories
Definition of Ready
Definition of Done
Get started working as a Scrum Team
The goal of this training is to help your Scrum Team get started on the right foot by establishing the four core team artifacts: Working Agreements, User Stories, Definition of Ready, and Definition of Done.
Build the Increment and own the Sprint Backlog
Maximizes value and owns the Product Backlog
Servant leader who coaches and removes impediments
Supports requirements and stakeholder communication
Rules your team lives by
Rules, disciplines, and processes the team agrees to follow to make themselves more efficient and successful. Created by the team, for the team.
| Purpose | What It Does |
|---|---|
| Shared Responsibility | Develop a sense of shared responsibility across the whole team |
| Self-Awareness | Increase members' awareness of their own behavior and its impact |
| Empowerment | Empower the team to operate according to their own agreements |
| Group Quality | Enhance the quality of the group process and team dynamics |
| Reviewed Regularly | Reviewed at every retrospective and updated as needed |
| Communication | Distributed teams use video daily · Co-located teams sit together |
Telling the story from the user's perspective
A User Story is a tool/technique used in Agile to capture a description of a software feature from the end user's perspective. It describes the type of user, what the user wants, and why the user wants it.
As a logged in user, I need to be able to update my contact information, so that your organization can successfully contact me.
💡 A User Story is a trigger for conversation between the Product Owner and the Development Team — not just documentation. The story sparks the discussion; the discussion produces the details.
| Waterfall Works When… | Agile Works Best When… |
|---|---|
| What we know far exceeds what we don't know | What we DON'T know far exceeds what we know |
| Processes are well established and well defined | Processes are not well established or defined |
| Everyone already has the needed domain knowledge | We are seeking continuous improvement |
| We are NOT trying to learn through experimentation | We are actively learning through validated experimentation |
How to use user stories effectively
Small enough to fit on a single index card. Keep it concise and focused on one user need.
A pointer to a conversation between the Product Owner and developers. It sparks dialogue.
Testable and independently confirmable. Clear acceptance criteria confirm completion.
| I | Independent | Can be developed and delivered without depending on another unfinished story |
| N | Negotiable | Not an immutable contract — details and implementation can evolve |
| V | Valuable | Delivers clear, meaningful value to the intended user or the business |
| E | Estimable | The team has enough information to estimate the effort involved |
| S | Small | Small enough to complete within a single Sprint — if not, split it |
| T | Testable | Has clear acceptance criteria that can be independently verified |
Acceptance criteria make or break a story
Acceptance Criteria are all of the things that must be true for the story to be considered complete. They are listed as testable conditions under the user story.
How epics become stories
Bigger stories can be broken down until they are actionable. The acceptance criteria of the parent story (the epic) become independent but related child stories.
As a super administrator, I need to be able to manage administrator accounts, so that I can ensure only authorized employees have administrator access.
As a super administrator, I need to be able to create administrator accounts, so that I can ensure only authorized employees have administrator access.
As a super administrator, I need to be able to read (view) administrator accounts, so that I can ensure only authorized employees have administrator access.
As a super administrator, I need to be able to update administrator accounts, so that I can ensure only authorized employees have administrator access.
As a super administrator, I need to be able to delete administrator accounts, so that I can ensure only authorized employees have administrator access.
When stories are too big, split them
When stories are too large to complete in a Sprint, Product Owners must split them. Use S.P.I.D.R. as your guide:
Is the story ready to enter the Sprint?
The standard by which all Product Backlog Items are compared to determine their readiness for consumption into a Sprint. Shared by the entire Scrum Team.
| Criteria | What It Means |
|---|---|
| 👥 Shared by the Team | The DoR is shared and agreed by the entire Scrum Team |
| ✅ Encompasses All Work | Covers all work that must be done for it to be truly ready |
| 📐 INVEST Criteria Met | Story is Independent, Negotiable, Valuable, Estimable, Small, and Testable |
| 📝 Clear Acceptance Criteria | Acceptance criteria are clear, complete, and testable |
| 🔍 Reviewable | Team understands how to demonstrate the story at the Sprint Review |
| 🔗 Dependencies Identified | External dependencies are identified and documented — or resolved |
How do we know the work is truly complete?
The standard by which all work is compared to determine its completeness. Shared by the entire business. The backstop for all estimations. A quality contract the entire team is accountable for.
| Principle | What It Means |
|---|---|
| 📍 Factual | Based in the NOW — reflects CURRENT processes, procedures, and practices |
| 🌱 Not Set in Stone | Grows with the maturity, continuous improvement, and experience of the team |
| 🏢 Layered Guidance | May have minimums set by the organization — teams can set stricter standards |
Situation: Even though the team met their DoD, users complained about slow performance after deployment.
Lesson: The DoD did not include performance testing. A complete DoD must address non-functional requirements — performance, security, and usability — not just functional acceptance criteria.
Situation: The training department was not notified of application changes and had to scramble to keep up.
Lesson: The DoD did not include a notification process. A robust DoD includes communication and documentation requirements — think beyond code: who else is affected by this release?
Two states of every backlog item
Think of the Definition of Ready and the Definition of Done as two states of product backlog items during a Sprint cycle. Every story must pass through both gates.
Stakeholder Deep Dive Training and Workshop
Continued training sessions for the full Scrum Team
Dedicated Product Owner training and coaching
Dedicated Scrum Master training and practical coaching
Cross-team alignment and kickoff session
Practical Agile Mentoring · mickymarvels.info · +1 (213) 440-2770