Please enable JavaScript.

Coggle requires JavaScript to display documents.

Scrum Roles - Coggle Diagram

- - - - creates a product vision together with the stakeholders
      - Every decision is taken with the product vision in mind
    - - Customer delight is the ultimate goal
    - - For example, when building a house the roof
        might have the highest priority considering possible rain
    - - User stories are explained in a personal conversation
    - - Examples are Business Model Generation, Lean Startup or Impact Mapping
    - - seminars and conferences are a great way to share
        experiences and gather knowledge
    - - The visualization enables you to see the big picture of the product backlog
    - - A great Product Owner has a focus on functionality and the
        non-functional aspects of the product
      - Hours or even story points are less important
    - - A great Product Owner has in depth (non-)functional product knowledge and understands the technical composition
    - - This includes understanding the organization paying for the development but also
        being aware of the latest the market conditions
    - - A Product Owner should know how to explain the product strategy at board level, create support at middle management and motivate the development team with their daily challenges
    - - Every product needs a vision (level 1)
      - which will provide input to the product roadmap (level 2) The roadmap is a long range strategic plan of how the business would like to see the product evolve
      - Based on the roadmap, market conditions and status of the product the Product Owner can plan releases (level 3)
      - During the Sprint Planning (level 4) the team plan and agree on Product Backlog Items they are confident they can complete during the Sprint and help them achieve the Sprint Goal
      - The Daily Scrum (level 5) is used to inspect and adapt the team's progress towards realizing the Sprint Goal.
    - - A great Product Owner is available to the stakeholders, the customers, the development team and the Scrum Master
    - - Adding items to the backlog knowing nothing will happen with them only creates 'waste' and false expectations.
    - - He has a keen eye for opportunities, focuses on business value and the Return On Investment and acts proactive on possible risks and threats. Everything with the growth (size, quality, market share) of his product taken into account.
    - - technical innovation, bugs, defects, non-functional requirements and experiments, should also be taken into account.
    - - As a consequence, the opportunity to build the right product with the desired quality will also increase
  - - - One Product Backlog is used to describe the upcoming work on the product
      - When working with multiple teams on one product, you only need exactly one Product Owner
    - - Having many POs encourages micromanagement of teams
      - Many POs requires coordination and alignment
      - Many POs bring unclear responsibility and ownership
        
        create their own backlog, creating more complexity
- - - - XP provides practices and rules that revolve around planning, designing, coding and testing. Examples are refactoring (continuously streamlining the code), pair programming, continuous integration (programmers merge their code into a code baseline whenever they have a clean build that has passed the unit tests), unit testing (testing code at development level) and acceptance testing (establishing specific acceptance tests).
    - - Each item is finished as quickly as possible by having many people work on it together, rather than having a series of handoffs.
    - - . A spike is a concise, time-boxed activity used to discover work needed to accomplish a large ambiguous task. Great Development Teams uses spike experiments to solve challenging technical, architectural or design problems
    - - They understand that the quality of the Product Backlog is the foundation for a sustainable development pace and building great products
    - - always leave the code base in a better state than you've found it
    - - They need some slack to be
        innovative and creative
      - And when the sprint doesn't contain any emergencies: great! This gives the team the opportunity for some refactoring and emergent design. It's a win-win!
    - - conversations to plan, align, and to reflect
        
        we won’t know what we are doing (planning)
        
        we won’t know where we are going (alignment)
        
        and we’ll keep repeating the same mistakes (reflection)
    - - They are in direct contact with them. They truly understand what they desire and are therefore able to make the right (technical) decisions
    - - Great Development Teams understand the importance for non-functional requirements like e.g. performance, security and scalability. They can explain the (business) value to their Product Owner and customer and hereby ensure its part of the product backlog
    - - deliver features continuously
    - - They are able to deliver business value in the first sprint
    - - Everyone is doing the stuff that's necessary to achieve the sprint goal
    - - they collaborate with the Scrum Master to update the board
    - - understand the importance of technical/architectural innovation. They know it's necessary to keep up with the rapidly changing environment and technology.
    - - The only reason to use it is to make the 'done state' transparent for their stakeholders
    - - They give feedback whenever it's necessary, and don't postpone feedback until the retrospective
    - - Whenever specific skills are necessary, they collaborate with other teams to discuss the opportunities of 'hiring' specific skills
    - - Therefore they rotate developers across different modules of the applications and systems to encourage collective ownership
    - - don't focus on story points anymore. They've refined the product backlog so that the size for the top items don’t vary much. They know how many items they can realize each sprint. Counting the number of stories is enough for them
- - - - whose focus is on the needs of the team members and those they serve (the customer
    - - coaching the individual with a focus on mindset and behavior
    - - responsible for managing impediments, eliminate waste, managing the process, managing the team’s health, managing the boundaries of self-organization, and managing the culture
    - - that transfers agile knowledge and experiences to the team
    - - to ensure Scrum and other relevant methods are understood and enacted.
  - - - He understands Tuckman's different stages of team development
    - - Healthy conflict and constructive disagreement can be used to build an even stronger team
    - - some changes will only occur by being disruptive
    - - they don't need him anymore on daily basis
    - - The lessons learned after a mistake might be more valuable than some good advice beforehand
    - - encourages and coaches the team to take
        ownership of their process, task wall and environment
    - - they make their own decisions about their work, estimate their own work, have a strong willingness to cooperate and team members feel they are coming together to achieve a common purpose through release goals, sprint goals and team goals
    - - The sprint rhythm should become the team’s heartbeat, which doesn't cost any energy
    - - He observes the session and hereby has a more clear view to what is being discussed (and what isn't) and what everyone’s role is during the standup
    - - shares experiences with peers
    - - He knows what format is most suitable given the team's situation
      - Even better: he supports the team by hosting their own retrospective
    - - he can help the team members understand themselves better so they can find news ways to make the most of their potential
    - - knows how to motivate and influence at tactic and strategic level
    - - he prevents them. Due to his experiences he is able to 'read' situations and hereby act on them proactively
    - - He doesn't disturb the team unnecessary and supports the team in getting into the desired 'flow'. But when the team needs him, he's always available
    - - the Product Owner 'pushes' the team, the Scrum Master protects the team
    - - "leadership isn't just a title, it's an attitude"
    - - engage users in solving problems and increase users' contribution
    - - He tries to understand what a team wants to achieve and helps them become more effective in an agile context
    - - is someone that team members want to follow. He does this by inspiring them to unleash their inner potential and showing them the desired behavior. At difficult times, he shows them how to act on it; he doesn't panic, stays calm and helps the team find the solution
    - - A great Scrum Master has facilitation as his second nature. All the Scrum events are a joy to attend, and every other meeting is well prepared, useful and fun, and has a clear outcome and purpose
- - - - Be who they need to be to deliver value
    - - Part of community that allows them to become more masters of their craft
    - - Purpose driven direction
- - - - Create story mapping
      - We dont measure you as a business analyst, we measure the team as the value that deliver
      - Create a good questions
    - - We need that skills that PM have
      - Compliance Documentation