Useful links

Posters

Professional Scrum Competencies

  • Understanding and Applying the Scrum Framework: Empiricism, Scrum Values, Scrum Team, Events, Artifacts, Done.
  • Developing People and Teams: Self-Managing Teams, Facilitation, Coaching and Mentoring.
  • Managing Products with Agility: Forecasting & Release Planning, Product Value, Product Backlog Management, Stakeholders & Customers.
  • Developing & Delivering Products Professionally: Emergent Software Development, Managing Technical Risk, Continuous Quality, Continuous Integration, Continuous Delivery, Optimizing Flow
  • Evolving the Agile Organization: Organizational Design & Culture, Portfolio Planning, Evidence Based Management

Understanding and Applying the Scrum Framework

Empiricism

Manifesto for Agile Software Development:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans. Scrum also places great emphasis on mind-set and cultural shift to achieve business and organizational Agility

3 Pillars of Empiricism:

  1. Transparency - we all know what is going on
  2. Inspection - check your work as you do it
  3. Adaptation - ok to change tactical direction

Agile:

  • Agile is a set of values and principles (Agile Manifesto)
  • Agile is a way of developing software that reminds us that although computers run the code, it’s people who create and maintain it (The Agile Samurai).
  • Agile is the courage to be honest enough to admit that building software is complex and it can’t be perfectly planned since requirements change.
  • Constant change, constant continual learning

The 7 Principles of Continuous Innovation

  1. Delighting Clients - “Focus work on delighting the client”
  2. Self-Organizing Teams - “Do work through self-organizing teams”
  3. Client-Driven Iterations - “Do work in client-driven iterations”
  4. Delivering Value to Clients in Each Iteration - “Deliver value to clients in each iteration”
  5. Radical Transparency - “Be totally open about impediments to improvement”
  6. Continuous Self-Improvement - “Create a context for continuous self-improvement by the team”
  7. Interactive Communication - “Interactively share stories, questions, conversations”

4 levels of trust to be built:

  1. Leadership trusting the teams
  2. Teams trusting leadership
  3. Team members trusting each other
  4. Trust yourself

Scrum Values

The Scrum values help teams adopt Scrum and deliver amazing software for their customers. And, they also create a great place to work.

Scrum Values:

  1. Focus - everyone focuses on the work of the sprint and the goals of the scrum team
  2. Openness - scrum team and its stakeholders agree to be open about all the work and the challenges with performing the work
  3. Courage - scrum team members have courage to do the right thing and work on though problems
  4. Commitment - people personally commit to achieving the goals of the scrum team
  5. Respect - scrum team members respect each other to be capable, independent people

Cultural environment is necessary for success, we could try to make the Scrum Values real by focusing on six principles:

  1. Self-organization
  2. Done means done
  3. Empowered Product Owners
  4. Servant-leader Scrum Masters
  5. Scrum Team ownership for adaption
  6. The delivery of business value

As a Scrum Master, you demonstrate servant leadership by coaching with the Scrum values. There are 4 Ways to Coach with the Scrum Values:

  1. Establish what the Scrum values mean to us as individuals and as a team.
  2. Use the Scrum values to help guide decision-making.
  3. Observe and discuss outcomes and behaviors and refine what the Scrum values mean to us.
  4. Identify actions for improvement.

Scrum Team

Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach

The 8 Stances of a Scrum Master:

  1. Servant Leader
  2. Facilitator
  3. Coach
  4. Manager
  5. Mentor
  6. Teacher
  7. Impediment Remover
  8. Change Agent

Scrum has three accountabilities, each with a different focus :

  • Product Owner (what?)
  • Developers (how?)
  • Scrum Master

A great Scrum Master…

  • Ensures the entire team supports the chosen Scrum process;
  • Manages the impediments that exceed the self-organizing capabilities of the team and it prevents them in achieving the Sprint Goal;
  • Recognizes healthy team conflict and promotes constructive disagreement;
  • Is prepared to be disruptive enough to enforce a change within the organization;
  • Understands the power of self-management;
  • Understands the value of a steady sprint rhythm and does everything to create and maintain it;
  • Knows how to truly listen and is comfortable with silence;
  • Understands the strength of coaching and has learned some powerful questions by heart;
  • Teaches the Product Owner how to maximize ROI and meet objectives;
  • Is also competent with XP, Kanban, and Lean.

Scrum Master should always prevent a fully booked schedule. A smart Scrum Master has lots of free space in his/her agenda. The more the better.

The Scrum Master serves the Development Team in several ways, including: Coaching the Development Team in self-organization and cross-functionality.

As a daily preparation a Scrum Master could consider questions like:

  • How is my Product Owner doing?
    • Is the Product Backlog in shape?
    • How is he/she managing the stakeholders?
    • What about delivering business value and return-on-investment?
  • How is the Scrum Team doing?
    • Are they working together?
    • Is there conflict in the team, do they resolve that?
    • Is the team making decisions?
  • How are our engineering practices doing?
    • Is the team caring and improving them?
    • How is the test automation?
    • Is the team expanding their Definition of Done?
  • How is my organization doing?
    • Is there inter-team coordination?
    • What organizational impediments are in the way?
    • What about the HR practices?

A day in the life of a Scrum Master:

  • Start the day with an open and curious mind (and in my case some good coffee)
  • A good first question to consider is “How can I improve the life of the Scrum Team by facilitating creativity and empowerment?”
  • Remember: your agenda is as good as empty! Except for the Daily Scrum and maybe some other Scrum events
  • You attend the Daily Scrum as an observer. You listen to what is and isn’t being said.
  • You consider some of the questions I’ve mentioned earlier.
  • Based on your observations you determine your next steps. This might be coaching, consulting, teaching, facilitating, mentoring, managing, problem-solving, conflict navigating or… just sitting with the team, listening, and watching the team.
  • Doing “nothing” is a perfect activity for a Scrum Master! The biggest pitfall for a Scrum Master is being too busy and not noticing what is really going on.

Scrum Master:

  • Promotes and supports the use of Scrum
  • A focus on transparency
  • Is a Servant Leader
    • Service to others
    • Promotes a sense of community
    • Holistic approach to work
    • Shared decision-making power
  • Serves the PO, Team, and Organization

Scrum does not care about job titles

The Famous Spotify Model:

  • Squad: similar to a Scrum Team
  • Tribe: collection of Squads that work in a related area
  • Chapter: a family of people inside a Tribe with similar skills
  • Guild: a community of practice cross Tribe

Myth 8: The Scrum Master is a Junior Agile Coach

Events

The Scrum framework describes 5 events:

  1. The Sprint
  2. Sprint Planning
  3. Daily Scrum
  4. Sprint Review
  5. Sprint Retrospective

All events are time-boxed and enable progress through adaptation and transparency.

5 Powerful Things About the Sprint:

  1. Focus
  2. Predictability
  3. Control
  4. Freedom
  5. Opportunity

Artifacts

The Scrum framework describes 3 artifacts:

  1. The Product Backlog
  2. Sprint Backlog
  3. Increment

These artifacts provide the team with a minimal set of materials to plan, execute, and review the Sprint.

Myth 2: The Sprint Backlog can’t change during the Sprint

Although the Sprint Goal is fixed during the Sprint, the Sprint Backlog is not - Sprint Backlog is flexible, as long as changes do not distract from the focus on the Sprint Goal. In the context of the Sprint Backlog, the word “commitment” was replaced by “forecast”. However, commitment is still relevant for the Development Team; they commit themselves to:

  • Fulfil the Sprint Goal;
  • Delivering working, high-quality and usable software that meets the expectations of the customers and users;
  • Working only on the Product Backlog items with the highest value;
  • Focus on continuous improvement, learning, and technical excellence;
  • Continuously inspect and adapt, by which empiricism is supported;
  • Collaborate with all the business people involved;
  • The values and elements that build up the Scrum framework.

Where the Sprint Backlog is the expected output, the Sprint Goal is the desired outcome that we want to achieve. Instead of trying to cram as much as we can into a Sprint, our goal should be to reach the desired outcome (the Sprint Goal) with the least amount of output (Sprint Backlog).

Scrum Myth: The Sprint Backlog is a Commitment:

  • A set of Product Backlog Items that form a plan to realise the Sprint Goal
  • A forecast of functionality in the next increment
  • A forecast of the work required
  • An artifact to make visible all the work the Development Team has identified as necessary to meet the Sprint Goal

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

Sprint Goal

Myth: Having A Sprint Goal Is Optional In Scrum

Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum provides the minimal boundaries within which teams can self-organize to solve complex problems with an empirical approach.

“The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives”

Three important purposes of Sprint Goals:

  • They give guidance during the Sprint on the objective that the Scrum Team wants to achieve in the Sprint, as well as why that is important;
  • They help the Development Team focus on what (kind of) work is important, and what is not;
  • They promote collaboration by giving Development Teams one clear purpose to work on, instead of separate initiatives.

What happens without Sprint Goals …

  • a wide variety of items will be pulled from the Product Backlog during Sprint Planning
  • the Sprint Backlog is likely what Development Teams implicitly (or explicitly) commit to instead
  • no obvious incentive to collaborate - you are likely to see members of the team picking up ‘their own’ items from the Sprint Backlog and starting work on that
  • the Daily Scrum takes the form of a status update - you will hear more “I” than “We”
  • members will complete ‘all their work’ at different moments during the Sprint - without a shared objective to encourage people to identify opportunities to help each other, they will instead announce they have nothing to do
  • it is hard to know who to invite for the Sprint Review
  • the Development Team doesn’t have guidance on how to decide where to invest time and what to let go - it is likely that everything will be considered equally
  • it is hard to know when a Sprint is successful -a clear goal can be achieved, and then celebrated - without such a goal, completing the entire Sprint Backlog often becomes the goal
  • complain that Scrum Events take a lot of time and feel ineffective - Scrum Events will be experienced more like ‘meetings’ where there’s a lot of talking going on that is not relevant to everyone
  • without Sprint Goals, each Sprint implicitly has the same purpose: complete all the work - this makes all Sprints the same

“A Sprint is [ … ] the smallest possible time-box for a Scrum Team to deliver a coherent set of valuable features without losing focus”

Intermission: Examples of Sprint Goals:

  • Sprint 1: “This Sprint exists to set up our deployment infrastructure to deploy a secure, working login page.”
  • Sprint 2: “This Sprint exists to use-test the interface for entering hours”
  • Sprint 3: “This Sprint exists to allow flex agency employees to validate the hours submitted this week.”

Reasons for not having Sprint Goals:

  • Product Owners don’t have the mandate to decide what goes on the Product Backlog and in what order
  • Product Owners don’t have a vision or strategy for the product
  • Product Backlogs span thousands of items
  • Scrum Teams may be too large
  • Scrum Teams may work on different products or projects at the same time, making it hard to identify one singular goal for a Sprint
  • Sprints may be too short or too long
  • Scrum Teams may be organized as ‘component teams’
  • Scrum Teams often start with the Sprint Backlog and try to reverse-engineer a Sprint Goal
  • Some teams do work that is not suited to the time-boxed and purpose-driven nature of Sprints

Tips:

  • Help Product Owners plan ahead by identifying potential objectives for upcoming Sprints
  • use the Liberating Structure
  • ask powerful questions to help Product Owners dig deeper into the “Why” of their decisions - “If the entire Product Backlog was lost, what would be the first things you would bring back at this moment in time? Why?”
  • The Sprint Review offers potential objectives for the next Sprint(s)
  • Use a template to craft Sprint Goals
  • Make your Sprint Goal transparent
  • Begin each Scrum Event by stating the Sprint Goal
  • Don’t worry if you can’t relate all the items on a Sprint Backlog directly to the Sprint Goal
  • Find Sprint Goals that offer guidance during the Sprint and promote collaboration in your team;

“The lack of Sprint Goals is one of the biggest impediments facing Scrum Teams today.”

Challenges with the Sprint Goal:

  1. Challenge #1: There is no Sprint Goal
  2. Challenge #2: The work is the Sprint Goal
  3. Challenge #3: There is no room for anything else
  4. Challenge #4: There is no focus on the Sprint Goa
  5. Challenge #5: The goal is not a goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of a Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives (Scrum Guide, 2016).

Six Reasons Why You Need to Pay More Attention to the Sprint Goal:

  • The Sprint Goal gives the Development Team some flexibility
  • The Sprint Goal gives sense to the tasks and motivates the Team
  • The Sprint Goal unites the Development Team
  • The Sprint Goal helps in managing risks
  • The Sprint Goal helps with focus and making decisions
  • The Sprint Goal helps manage stakeholders’ expectations

The Sprint Goal provides guidance to why we are building the Increment

4 Challenges With Sprint Goals (and some tips for resolving them)

  1. The Sprint Goal is too big.
  2. The Sprint Goal is vague.
  3. The team doesn’t pay attention to the Sprint Goal during the Sprint.
  4. The Sprint Goal doesn’t feel meaningful.v

Done

The objective of each Sprint is to deliver an Increment. The Definition of Done (DoD) provides a way for the team to make what done means transparent.

Developers needs to decide what Done means within the organisational context and the product domain. They need to sit down and create a list of things that must be true for every Increment of software that they deliver.

“The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.”

Characteristics of a Definition of Done:

  • A short, measurable checklist
  • Mirrors shippable
  • No further work

Some examples of things to put on your definition of done:

  • Increment Passes SonarCube checks with no Critical errors
  • Increment’s Code Coverage stays the same or gets higher
  • Increment meets agreed engineering standards
  • Acceptance Criteria for Increment pass
  • Acceptance Tests for Increment are Automated
  • Security Checks Pass on Increment
  • Increment meets agreed UX standards
  • Increment meets agreed Architectural Guidelines

The Definition of Done is the commitment to quality for the Increment!

Growing your Definition of Done (DoD) - always look for ways that you can increase your quality

The tyranny of work which is nearly done, but not really done, can put a team in servitude to technical debt.

“Done” criteria which are needed to effect a release, but which cannot yet be observed, constitute a deficit. They should be enumerated here (e.g. by moving them out of the Definition of Done).

Definition of Done Should include a Definition of Undo(ne)

CI/CD/DCA - Continuous Integration + Continuous Delivery + Data Capture / Analysis

Myth 3: In Scrum, releases are done only at the end of the Sprint

The completeness of the increment is defined by the amount of time that is still needed to get the increment to users (e.g. to production). The more time is needed, the less Agile the organisation is.

Sprint represents a minimal boundary for when to deliver a “Done” increment. There is nothing in the Scrum Framework that prevents Scrum Teams from releasing working software throughout the Sprint, as long as the Product Owner is involved in the decision to release.

Demo of working software is only a small part of the Sprint Review. The primary purpose of this event is to inspect what was done during the Sprint and to decide what next things can be done to optimize value. The more “Done” the increment is, the more useful the feedback that is gathered will be. So if the team has already released working software during the Sprint, this makes the Sprint Review an excellent opportunity to inspect feedback from real users and adapt based on the insights that emerge from that. The value of the Sprint Review actually increases as the “Definition of Done” of a team moves towards “Released to production”.

Scaling

Scrum is designed to work at the team, product, and organization level.

Developing People and Teams

Self-Managing Teams

A fundamental foundational element to Scrum; cross-functional, self-managing and empowered teams are the engine to delivering value.

Facilitation

Facilitation is a set of practices that help support the collaboration, communication, and creativity of teams and individuals.

Agile Coach Toolkit #4: Effective Facilitation:

  • Purpose – As a Scrum Master, you will need to facilitate Scrum events, decision making, conflict resolution and other critical discussions. This will require some preparation and deliberation to ensure the goals are met.
  • Description – Facilitation is needed to ensure that the group works cooperatively and effectively. As a Scrum Master, you will need to take care of a few aspects to help meet the goal(s) of the discussion. Tips for effective facilitation are listed below:
    • Ensure that everyone participating in the discussion understand its purpose.
    • Working agreement at the beginning will help.
    • If the event/ meeting is not interactive, you may want to spend some time take some time to find the Root Cause.
    • Create a safe environment for people to speak by ensuring that people focus on task at hand rather than pointing fingers.
    • Use Timeboxing to ensure that discussions are productive.
    • Balance the discussions so that introverts feel included in the discussions.
    • As a facilitator, you need to read the mood in the room to take breaks at regular intervals to keep the energy level high for productive discussion.
    • Be neutral in your stance and do not take sides.

Agile Coach Toolkit #6: Building Consensus:

  • Have everyone understand the meaning of giving consent
  • Clearly articulate what needs to be decided
  • Before pitching for lengthy discussion, do a quick poll to check if there is consensus
  • If there is a disagreement amongst team members, allow everyone to voice their concerns during the discussion
  • List Scrum Values and ask people the follow them throughout the discussion
  • Leverage Timeboxing to ensure that you curtail lengthy discussions
  • For final decision, do another poll to see if majority of the team agrees
  • Ensure that the team decision is communicated at the end of the meeting

A powerful technique to improve your Scrum events - 1-2-4-All - Steps to use this Liberating Structure:

  1. Start with 1 minute of silent self-reflection by individuals on a shared challenge, framed as a question;
  2. Take 2 minutes to generate ideas in pairs, building on ideas from self-reflection;
  3. Create groups of four and use 4 minutes to share and develop ideas that you’ve discussed within your pair. Notice similarities and differences.
  4. Take 5 minutes to share insights, ideas and takeaways by asking “What is one idea that stood out in your conversation?”. Each group shares one important idea. Repeat cycle as needed.

Leadership Styles

There are many different leadership styles ranging from traditional ‘command and control’ to more collaborative or even Machiavellian. Understanding the right style to use at a given time and how different styles can influence - in a positive or negative way - the agile agenda of empiricism, empowerment, and improvement is a key Focus Area.

Leading High Performing Teams:

  • Goal
  • Leadership
  • Culture
  • Continual improvement
  • Transparency
  • Rapid experimentation
  • Fun

Autonomous teams are self-managing. Self-management requires two critical ingredients:

  • An absence of traditional management.
  • A light set of constraints. Constraints help balance autonomy with accountability. Constraints might be an iteration, a Sprint Review, a social contract or a facilitated meeting.

The Scrum Master acts as a:

  1. Servant Leader
    1. Commitment to put yourself last
    2. Focus on the greatness of others
    3. Respect other people’s needs to be fully human
    4. Courage to speak the truth
    5. Openness about own vulnerability
  2. Facilitator
  3. Coach
  4. Conflict navigator
  5. Manager
  6. Mentor
  7. Teacher

The 28 Characteristics of a Great Scrum Master:

  1. Involves the team with setting up to process
  2. Understands team development
  3. Understands principles are more important than practices
  4. Recognizes and acts on team conflict
  5. Dares to be disruptive
  6. Is aware of the smell of the place
  7. Is both dispensable and wanted
  8. Let his team fail (occasionally)
  9. Encourages ownership
  10. Has read…
  11. Has studied…
  12. Is RE-TRAINED.
    1. Resourceful
    2. Enabling
    3. Tactful
    4. Respected
    5. Alternative
    6. Inspiring
    7. Nurturing
    8. Empathic
    9. Disruptive
  13. Has faith in self-organization
  14. Values rhythm
  15. Knows the power of silence
  16. Observes
  17. Share experiences
  18. Has a backpack full of different retrospective formats
  19. Can coach professionally
  20. Has influence at organizational level
  21. Prevent impediments
  22. Isn’t noticed
  23. Forms a great duo with the Product Owner
  24. Forms a great duo with the Product Owner
  25. Is familiar with gamification
  26. Understands there’s more than just Scrum
  27. Leads by example
  28. Is a born facilitator

5 Agile Leadership Tips for Creating Mature Scrum Teams

  1. Focus on the people - Ask your Product Owners & Scrum Masters what you can do to help them grow in their role
  2. Dare to let go - Ask your Scrum Team what incentives could lead to a higher focus on customer value
  3. Lead by example - Ask your Scrum teams and fellow-leaders how do they perceive the 5 Scrum values in your organisation
  4. Avoid shortcuts - If you want fast adoption and growth, hire external expertise and create a setting where people can fail and learn fast
  5. Growing in the same pace causes less tension - Ask your Scrum team what organisational limitations keeps them from making decisions as a whole

Coaching & Mentoring

A key aspect of servant leadership is the ability to coach and mentor the organization, the team, and the business. The objective of coaching and mentoring is to help people get better at their work, deliver more value, or resolve a conflict or problem.

How to Build Trust to Enable Agility - BRAVING

  1. Boundaries - I establish clear boundaries, and I stick to my boundaries. You establish boundaries, and you hold your boundaries. We both respect each other’s boundaries.
  2. Reliability - I do what I say I will do. You do what you say you will do. Over and over and over again.
  3. Accountability - I hold you to account for doing the things you said you would do. You can hold me to account for doing the things I said I would do.
  4. Vault - What you share with me, I will hold in confidence. And I expect you to do the same with me.. and with others.
  5. Integrity - This is about choosing courage over comfort. This is about choosing what is right over what is simply fun, fast, or easy. Practice your values rather than just professing them.
  6. Non-Judgment - You can be struggling and ask for help, and I will not judge you. I can be struggling and ask for help, and you will not judge me.
  7. Generosity - You can assume the most generous things about my words, actions, and intentions. And I will do the same for you.

Coaching Secret: Stop being so helpful

  1. Moving towards action too quickly limits learning.
  2. Offering advice limits creativity and ownership.
  3. Owning the actions creates overwhelm for us and limits growth for others.

Coaching patterns:

  1. The Socratic Method. I ask a lot of questions and try to stimulate critical thinking.
  2. The dictatorial pattern. You literally dictate a solution.
  3. The mirroring pattern.
  4. Swarming.
  5. The voice from afar pattern.

Agile Coach Toolkit #5: Active Listening:

  1. Level 1: Internal listening
  2. Level 2: Focused listening
  3. Level 3: Global listening

Tips for Active Listening:

  1. Get rid of distractions like mobile phone, laptops or other electronics, move away from noisy places.
  2. Before the conversation, become self-aware by taking a moment to assess your mood and clear your thoughts.
  3. Maintain an open posture – unfold your arms, unclench your fists and keep good eye contact.

    Teaching

The ability to inspire others to learn and share information in an effective, repeatable, and efficient manner is a key aspect to any agile practitioners’ skills.

Managing Products with Agility

Forecasting & Release Planning

Complex problems and the application of an empirical process requires a specific way of planning, estimating, and forecasting.

“The most important metrics are: did we execute the way in which we said we would, and did we deliver the value to the business that we had promised?”

  • The Sprint Burndown
  • The Product Burndown

Myth 9: Story Points are Required in Scrum

As with previous posts, let’s start with what the Scrum Guide says on estimation. Although it states that “work may be of varying size, or estimated effort”, it does not prescribe how this estimation should be done. Although Scrum Teams should apply some sort of ‘estimation’, there is no mention of Story Points, hours, ideal days, gut feeling, t-shirt sizes or any other unit for that matter. The Scrum Guide does remind us to use an approach that respects the complexity of software development and to not let estimation replace the importance of empiricism itself.

“Use the empirical process of Scrum to capitalize on change rather than control against it.”

  • Accurate estimates are impossible
  • An estimate can’t be a guarantee
  • The time we spend on estimation is a form of waste
  • The estimates themselves are the result of a necessary conversation within the Development Team to arrive at a shared understanding.

“Time-based estimates uphold the illusion of accuracy and predictability.”

This is why the use of relative estimation, in particular ‘Story Points’, was popularized by Extreme Programming

#NoEstimates-movement

  • Use the number of items per Sprint (this requires that items are broken down to about equal size)
  • Use size buckets as a guide, where the Development Team classifies items in terms of size (e.g. large, medium, small)
  • Simply use the combined gut feeling of the Development Team to determine if enough work was selected for the Sprint.

“Estimating is often helpful, estimates are often not.” — Esther Derby

“Respect the complexity of software development, and don’t let estimation replace the importance of empiricism itself.”

Tips for Agile product roadmaps & product roadmap examples

  • Goal Oriented product roadmap (GO product roadmap)
    • Q1, Q2, Q3, Q4
    • Date, Goal, Key features and Metrics
  • Now-Next-Later product roadmap
  • Story map

11 Tips for Agile Product Roadmaps

  • Start with your product vision (tip: use Roman’s Product Vision board);
  • Describe and validate your product strategy;
  • Focus on goals and benefits, by creating a goal oriented product roadmap (or one of the other types I’ve explained before);
  • Tell a coherent story about the likely growth of your product and don’t oversell it;
  • Keep it simple! Resist the temptation to add too much details to your roadmap;
  • Actively collaborate with stakeholders to ensure buy-in;
  • Have the courage to say no, to prevent an overload of features in your roadmap;
  • Think twice about adding timelines, dates or deadlines to your roadmap;
  • Make sure your roadmap is measurable, by adding measurable goals and KPI’s;
  • Create a rough estimate for each feature (#people + required skills) to determine the viability of a feature;
  • Review and adapt your product roadmap on a regular basis.

Why is software so unpredictable

  • All software development is product development.
  • Manufacturing lives in the predictive world.
  • Software lives in the empirical world.

Accept the lack of predictability

Focus on continuous quality

“If you put developers under pressure to deliver they will continuously and increasingly cut quality to meet deadlines”

  1. Create a short measurable checklist that mirrors minimum releasable product (Defenition of Done)
  2. Stop adding new features and make your product meet that checklist and release your product
  3. While you have an increment of working software (Sprint)
    1. Work to create something of value (Increment)
      1. Work towards a new goal while meeting the DOD (Sprint Goal)
      2. Leave things better than you found them (Engineering Excellence)
    2. Review that thing of value with your stakeholders (Sprint Review, Backlog Adaption)
      1. Get feedback on at least one new thing for stakeholders
      2. Update the Backlog to reflect this new information
    3. Reflect on how you worked with your entire team (Sprint Retrospective, Kaizen)
      1. Is the quality increasing?
      2. Is the DOD increasing?
      3. What can we change to make things better?
  4. Go to #1

There are a number of strategies that can help you both stop creating and start paying back technical-debt:

  • Sufficient requirements
  • Developers choose what they can deliver
  • Definition of Done (DoD)
  • Test First
  • Fixed-length iterations
  • No separate teams
  • Manage dependencies
  • Use a modern source control system

INVEST (Independent, Negotiable, Valued, Estimable, Small, Testable )

Small batch delivery

Scrum Myths: There is No Planning in Scrum - The reality is we plan A LOT in Scrum. We just plan differently to optimize effectiveness.

  • In Scrum, we emphasize the activity of planning over the plan itself.
  • In Scrum, the activity of planning is collaborative.
  • In Scrum, the people doing the work own the plan.
  • Planning in Scrum is part of every Event.
  • In Scrum, the way planning is done reduces waste.
    • We minimize time spent analyzing things that may never happen.
    • We minimize time spent analyzing to an impossible level of accuracy.
    • We incorporate meaningful feedback every time we plan.
  • In Scrum, we still recognize the inherent unpredictability in complex software development.

    Product Vision

The product vision defines the purpose that the product aspires to fulfill. It is defined by the value that the product strives to deliver.

Our book aims to fill that gap by bringing empowerment and entrepreneurship to the role. In other words, Product Owners should be initiating innovation and functionality, not just receiving it.

When we thought about what a professional Product Owner needs to do in order to achieve this, we came up with the three Vs — Vision, Value, and Validation:

  • Vision: the best thing a Product Owner can do to truly take ownership and inspire others is to establish and communicate a clear vision for the Product. Why are we building it? Whose lives will be improved by it?
  • Value: the best thing a Product Owner can do to move away from a project mindset (time, budget, scope) to more of a product mindset (value to stakeholders) is to define and communicate what success looks like. Is it customer satisfaction? Operating costs? Registrations? How will we measure it? How do we know when the value received no longer outweighs the costs?
  • Validation: the best way a Product Owner can actively manage risk is to shorten the feedback loop by validating frequently with internal experts and, even better, with the external marketplace. A professional Product Owner knows that the only way to move the needle on any value measurement is to release to customers. Until then, everything is just a hypothesis.

A professional Product Owner embraces empiricism as a way to address the complexity and risk of building something unknown. The three Vs fit perfectly with the three pillars of empiricism:

  • Vision creates Transparency.
  • Defining Value provides you with something to Inspect.
  • Validation causes Adaptation.

Why – How – What: From Product Vision to Task

  • Why you are doing it
  • How you are doing it
  • What you are doing

Golden Product Circle:

  • Vision (why)
  • Product Backlog (how)
  • Task (what)

Since „people don’t buy what you do, but why you do it“, please Start With Why for your product development with Scrum.

Product Value

The ultimate goal is to deliver value to the customer and stakeholders. But value is complex, made up of long-term and short-term impact, internal and external value, and indirect and direct value.

Delivery models:

  • plan driven (waterfall)
  • value driven (scrum)

Scrum is a process framework for resolving complex problems iteratively and incrementally to a create a high-value solution that elates customers. Scrum directly addresses many of the shortcomings of Waterfall with project management.

Scrum is:

  • Empirical instead of predictive - BASE YOUR DECISIONS AND PROCEDURES ON EXPERIENCE AND EXPERIMENT
  • Iterative instead of sequential - ORGANIZE YOUR WORK INTO SMALLER STEPS
  • Concentrated on gathering continuous feedback instead of gathering in stages - STAY ALIGNED WITH CUSTOMERS AND STAKEHOLDERS
  • Value-focused instead of deadline-focused - THIS IS YOUR PRIMARY FOCUS
  • Self-organizing instead of control and command - EMPOWER TEAM MEMBERS TO SELECT AND HOLD RESPONSIBILITY FOR THEIR WORK

Product Backlog Management

The Product Backlog is a key artifact within Scrum. It is an ordered list that describes what is needed in the product. The Product Backlog provides transparency into what is happening to the product for the team, organization, and stakeholders.

The Art of Product Backlog Refinement - According to the Scrum Guide, Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. But Scrum doesn’t prescribe how you do it, and for good reason.

Refinement is an ongoing process. It never stops because requirements and opportunities never stop changing. Detailing everything up front would create waste and also delay the delivery of value.

Different products and different teams will have unique needs in terms of frequency, techniques, and level of detail.

The Goldilocks Principle is about finding what is “just right” for your team. The goal is to balance gaining enough benefits from the activity while minimizing the potential waste. Let’s first look at the 6 benefits of Product Backlog refinement:

  1. Increase transparency
    1. How well do stakeholders and the Scrum Team understand what is planned for the product?
    2. How frequently are the interested stakeholders surprised by what was delivered?
  2. Clarify value
    1. How often do you discover during a Sprint that there is not a shared understanding of the business need or what you are building to meet it?
    2. How frequently do you discover in a Sprint Review or after a release that a PBI does not meet the user or business need?
  3. Break things into consumable pieces
    1. How often are you not delivering a “Done” Increment? How often are you not meeting a Sprint Goal?
    2. When is this attributed to discovering mid-Sprint that PBIs are much bigger than you thought or not sliced thin enough?
  4. Reduce dependencies
    1. How often do you discover dependencies during a Sprint that jeopardize the Sprint Goal?
    2. How long do PBIs in a Sprint stay “blocked” by dependencies?
    3. When do you have to re-order the Product Backlog to account for dependencies? And how much of an impact does this have on the Product Owner’s ability to optimize value?
  5. Forecasting
    1. How much lead time is necessary for users, customers, and other stakeholders to implement a new feature or function? What is the impact if they have less lead time?
    2. How much detail do users, customers, and other stakeholders need in release forecasts? What is the impact if they have less detail?
  6. Incorporate learning
    1. How are you adapting the Product Backlog to reflect new learning about the product’s evolving capabilities and how users are responding to the changes?
    2. What opportunities have been missed? What prevented you from responding sooner?

With the information gained from exploring 1-6, the Scrum Team can now consider these questionswith the balance of benefits and waste in mind.

  1. How frequently do you want to do refinement? And how much time do you want to spend detailing the Product Backlog?
  2. Who do you want to be involved in refinement? What knowledge and perspectives are needed? How will you enable shared understanding?
  3. How much of your Product Backlog do you want to be “Ready” before a Sprint? What does “Ready” mean to you?
  4. How do you want to communicate important details about PBIs? What methods are working well and what methods are not?
  5. How will you ensure you can see the whole and not get bogged down in details?

Five strategies that help Scrum Teams to refine the Product Backlog:

  1. Gaining insights
  2. Ordering the Product Backlog
  3. Estimating Product Backlog items
  4. Breaking down of Product Backlog items
  5. Eliminating dependencies

Myth: Refinement is a required meeting for the entire Scrum Team - The Scrum Guide describes Product Backlog refinement as the act of adding detail, estimates and order items in the Product Backlog. It goes on to describe that this is an ongoing collaboration between the Product Owner and the Development Team and that the Scrum Team as a whole decides how and when to do this.

Scrum provides a lightweight framework for allowing learning to happen as quickly as possible without losing the focus needed for solving complex problems.

Items on a Product Backlog are essentially reminders of conversations that we will need to have in the future.

If your Backlog is not Refined then you are Doing it Wrong

Business Strategy

A product lives within the context of a business strategy. That strategy describes how the Product Vision will be executed in a broader context.

Stakeholders & Customers

Effectively working with stakeholders and customers is a key skill for everyone on the Scrum Team. Scrum changes the nature of the interactions, encouraging more frequent collaboration and more open dialogue.

Developing & Delivering Products Professionally

Emergent Software Development

In solving complex problems, the idea of a detailed up-front design has been replaced with an approach that encourages design to emerge and change within the boundaries of an architecture.

Managing Technical Risk

All products have an inherent set of risks to manage. These risks range from the ability to deliver to technical risks associated with performance and security.

Continuous Quality

Working in an agile way does not change the importance of product quality. It does, however, change when and where quality is addressed.

Continuous Integration & Continuous Delivery

Frequent learning is a fundamental concept for Scrum. Continuous Delivery and Continuous Integration are a key collection of practices that enable frequent observation of working features.

Optimizing Flow

The Sprint is a time-box with clear flows within it. For large, complex work, the Sprint is just a small part of a broader flow for the product, business, or even market.

Evolving the Agile Organization

Organizational Design & Culture

Traditional organizations are often structured around Taylorism and mass production concepts in response to simple problems. Complex problems require a different way of organizing.

Portfolio Planning

For many large organizations, work is being undertaken in the context of a broader portfolio. That portfolio could be a product, system, value stream, supply chain, or even a program.

Evidence Based Management

A fundamental element of Scrum is empirical process; the idea that complex problems require real experience to effectively plan and deliver value. Evidence-Based Management (EBM) is a set of ideas and practices that describe broad measurement areas used to provide an effective, empirical, and value-based approach to any product.