| Table of Contents |
|---|
Key Points
...
Scrum Ceremonies The Unusual But Surprisingly Robust Guide gdrv
Scrum meeting - standup
- The attendees of the daily scrum include the scrum team, the scrum master, and the product owner.
- What was done. What's next. What are the blockers
- Daily Scrums are held for team members to share what blocks they’re facing so other members of the team can provide help.
- Some teams have found great success in doing their daily scrums over Slack via chat.
- make every team member share if they are facing any obstacles keeping them from making progress.
- Then, only developers who want to elaborate on their problems or provide solutions can stay; others can hop off the meeting and get to work.
- Focus on results not on sprint working hours, and you’ll have more success with your projects and your team in general.
Sprint Retrospective
- improve our working flows and thus deliver awesome results at the end of every sprint.
- retrospectives are held right after the sprint review at the end of the sprint
- great for clearing up bottled up feelings and emotions. Don’t let your team burnout; instead do a retro, and clear things out.
- share notes on what was good, what can be improved
- Retros should feel like a safe place where everybody can share their concerns.
- Treat each other with respect and focus on fixing problems instead of blaming others.
- Address all the negative shit but keep the positive attitude on point - “everything is figureoutable.“
- Don’t let only one or two team members dictate the pace and direction of the meeting. Every single member of the team should be active during the retro; that way, it feels more energetic; it bonds the team.
- You can suggest that team members jot down their thoughts on notes before the scrum event if that would make it easier to participate in the conversation
...
- You can try the “speedboat” method. Draw a speedboat. Attach a strong motor to it and a heavy anchor.
Get team insights
Asking questions can be quite helpful as well:
- What were the roadblocks? What were the challenges in this Sprint? What's the impact if they didn't exist?
- What went well this sprint?
- What did we learn?
- What should we do differently next time?
- What still confuses us?
Retro Decisions
- Each team member writes down two action items for the next iteration.
- The team reviews all suggestions and narrows to 1 or 2 to implement in the next sprint
Scrum Method
Delivery done in Sprints
Prereqs to Sprints
- Project resources
- Project Charter
- Project funding
- Project support
- Project Structure
- Project Documentation
- Project Governance
Sprint Roles
- Product Owner
- Scrum Master
- Team
- Champions
- Sponsors
- Consumers
Agile "GAPS" - customize
- DOQ - Definition of Quality
- DOR - Definition of Ready
- DOD - Definition of Done
Sprint Process: Plan, Deliver, Review, Assess
- Sprint Planning
- Execution
- The Sprint Review
- Sprint Retrospective
Sprint Planning
Sprint Plan - What and How decisions
- print planning is about coming up with the complete sprint plan for your next iteration.
- According to the Scrum guide, There are 2 main questions that the sprint planning ceremony:
- What can be delivered in the Increment resulting from the upcoming Sprint?
- How will the work need to deliver the Increment be achieved?
- selecting the right PBIs (product backlog items) and then ordering them by priority in the sprint backlog.
- break their PBIs into smaller tasks that would take them no more than 2 days to complete each.
- create Epics and Stories to define details for solution delivery based on use cases
- add dependency links as needed
Sprint Goal
- a mature scrum team is supposed to deliver between 85 and 115% of the planned work every sprint.
- allot 10% of its capacity to build out the product/sprint backlog before the start of the sprint
- items from previous sprints aren’t considered to be the main work of the new sprint. No points should be credited to completing work from previous sprints.
Backlog Refinement as needed
- detail, improve, estimate, and prioritize the PBIs in the sprint backlog as changes occur.
- PO and at least one member of the team are the required attendees
- set a time limit, of 10 minutes for example, per each backlog item.
- Planning poker - assessing the difficulty of each task, one developer might score 1 while another 5 on a scale of 1 to 5 (where 1 is easy and 5 extremely difficult).
- Discuss reasons for scores - come to the mode
Sprint Delivery - Execution, Standups
- Standups normally daily
- Identify what's done, what's in next, what are the blockers
- Create update reprioritize Jira tickets as needed
- Work as a team to resolve issues, blockers, prioritizations
Sprint Review
- What’s been done during the sprint?
- held to encourage collaboration and make the team operate as a whole so it can grow.
- allows developers to showcase their work to stakeholders; thus receive feedback and improve the way they approach work in future sprints.
- the dev team reviews what went well, wrong, and how team members handled difficulties throughout the sprint.
- As opposed to the scrum retrospective where “the how” is discussed.
- demo work is presented to stakeholders by the PO.
whether the sprint release was successful or not:
- What did the customers like about it?
- What did they dislike?
- What’s hard to understand from a customer POV?
- What changes do they want?
- What new features do they want to be added?
- Has the market changed? Do they have different problems?
- talk about how the market reacted to the new release, and then offer suggestions to improve the product.
- the product backlog can be frequently adjusted, especially during the sprint planning session for the next sprint.
Sprint Retrospective
- How well was the sprint done?
- How can Sprint planning, estimation and prioritization improve?
- How can Sprint execution improve?
- How can Sprint quality improve?
- How can Sprint productivity, velocity improve?
- How can team skills improve?
- What changes are needed to plans?
- What changes are needed to the team?
Coaching team members
https://www.scrum.org/resources/blog/how-scrum-master-can-be-co-active-scrum-coach
...
coaching model: every single coaching conversation. there are five contexts of Co-Active Coaching - listening, intuition, curiosity, deepen/forward, self-management.
Scrum Values - courage, focus, commitment, respect and openness are the lifeblood that breathe life into Scrum
Coaching principles
fulfillment helps coachees make choices that are aligned with their life purpose and core values.
balance can help the coach get the coachee get unstuck from beliefs that are no longer serving them.
process helps coachees experience all the ups and downs of their lives and be with emotions that they have trouble being with
SAFe framework - use common sense and fit to purpose to implement
...
ART - Agile Release Train
- CollaborationThe ART structure encourages collaboration between teams that might otherwise be siloed.
- PredictabilityThe fixed cadence of the PI allows for a reliable and predictable delivery of software.
- FlexibilityThe decoupling of release and deployment from the development cadence gives the organization flexibility over when and how to release to customers.
- AlignmentThe ART process involves aligning ART priorities with the overall portfolio strategy.
- PlanningThe PI planning process involves teams creating and agreeing on PI Objectives, and Business Owners sharing business and customer context.
- BacklogThe ART backlog includes the features that need to be delivered in a PI, which are then broken down into user stories for the sprint level backlog
LeSS Agile Framework
https://www.atlassian.com/agile/agile-at-scale/less
Agile teams are made up of product owners, scrum masters, software developers, and others who work collaboratively to address complex problems through the creative delivery of valuable products. Scrum is one of the more popular agile methodologies that teams use to develop, deliver, and sustain complex products. Yet only recently have we effectively addressed scaling scrum in the enterprise with scaled agile process frameworks like Large-Scale Scrum (LeSS).
LeSS is a framework for scaling scrum to multiple teams who work together on a single product. It starts with a foundation of one scrum team, as defined by Ken Schwaber and Jeff Sutherland in the Scrum Guide, and applies to multiple teams who work together on one product.
This is further refined in the book Large-Scale Scrum: More with LeSS, by Craig Larman and Bas Vodde. The authors condensed their years of experience to define LeSS as a framework to deliver value while reducing complexity and waste.
The LeSS framework seeks to apply the principles and ideals of scrum in a large-scale enterprise context as simply as possible through defined rules and guides. Its simplicity has earned LeSS the label of being a “barely sufficient” framework, but that’s not meant to cast it in a negative light.
The LeSS framework structure
LeSS was forged through more than 600 experiments that involved expanding the practice of scrum, which at the time was thought to only support small, colocated groups. The LeSS experiments, guides, frameworks, and principles were created to support the needs of larger numbers of teams. In addition, LeSS rules were later released to better define and provide guidance on how to implement and execute LeSS and offer guides for adoption.
Principles, frameworks, guides, and experiments
Principles
LeSS defines 10 principles for applying the value, elements, and overall purpose of scrum across an enterprise. They help create more responsible teams with greater customer focus and collaboration. Teams focus on learning, transparency, and delivering customer-centric values that product organizations need to remain competitive and responsive. Here’s the complete list:
- Large-Scale Scrum is scrum
- Empirical process control
- Transparency
- More with less
- Whole product focus
- Customer-centric
- Continuous improvement towards perfection
- Systems thinking
- Lean thinking
- Queuing theory
Frameworks
LeSS offers two configurations: Basic LeSS for two to eight teams (10-50 people) and LeSS Huge for more than eight teams (50-6000+ people).
LeSS Huge starts with the Basic LeSS foundation in place and adds a key role – the area product owner (APO) – and additional artifacts and meeting changes. It’s recommended to start with Basic LeSS in your organization – to experiment, experience, and get feedback – before jumping straight into LeSS Huge. There are two suggested approaches to LeSS Huge adoption:
- One requirement area at a time, focused on a requirement area within the larger product
- Gradually expanding the scope of work of the team, definition of done, and the product definition
This allows an organization to build team experience with LeSS, expand throughout a product area, and gain management support, before scaling LeSS throughout the whole organization.
Less Differences
LeSS shares five main components akin to other frameworks for scaling agile: inspiration from the Agile Manifesto and its 12 principles, cadence through sprints/iterations, synchronization across the organization, its roots in scrum, and quality development practices such as DevOps, CI/CD and test-driven development (TDD). But there are other distinguishing characteristics that set it apart from the rest.
Beyond this, in LeSS, sprint planning is broken out into two parts: 1) all teams come together to decide how to best divide the product backlog items and 2) teams plan their sprint, while collaborating and communicating with other teams to deliver the product backlog items.
Aside from these points, other ceremonies such as the daily scrum, sprint review, and overall retrospective, have their own nuances in LeSS.
Less vs Safe frameworks
Contrary to LeSS, SAFe requires additional roles, including the Release Train Engineer (RTE), Solution Train Engineer (STE), and Epic Owners. It also includes processes, artifacts, and organizational changes that some organizations may not be ready to take on; even despite starting on equal footing with agile teams successfully running scrum. LeSS Huge does provide some differences of Basic LeSS, but for the most part is not as complex as other frameworks.
Agile Product Management Journey
Agile-Product-Managers-Can-Build-Better-Products-by-ProductPlan.pdf link
Agile-Product-Managers-Can-Build-Better-Products-by-ProductPlan.pdf file
Potential Value Opportunities
Potential Challenges
Candidate Solutions
Step-by-step guide for Example
| Info |
|---|
sample code block
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
Recommended Next Steps
Related articles
| Page Properties | ||
|---|---|---|
| ||
|