![\"\"](\"\/wp-content\/uploads\/2019\/01\/Scrum1-300x179.png\")
<\/p>\n
<\/a>What is Scrum?<\/h5>\nScrum is not a fully-featured project management methodology. Rather, it describes an approach to Agile management with a focus on project teams, short “sprints” and daily stand-up meetings.<\/p>\n
While it borrows the principles and processes from Agile, Scrum has its own specific methods and tactics for dealing with project management.<\/p>\n
“Agile is the philosophy and Scrum the methodology. While Scrum is agile, agile isn\u2019t scrum.”<\/em><\/p>\nThe Scrum approach places the project team in front and center of the project. Often, there is no project manager. Instead, the team is expected to be self-organizing and self-managing. This makes it ideal for highly focused and skilled teams, but not so much for others.<\/p>\n
![\"\"](\"\/wp-content\/uploads\/2019\/01\/scrum2-300x214.png\")
<\/p>\n
<\/a>Advantages of Scrum<\/h5>\n\n- Scrum “sprints”<\/strong>: The Scrum approach is heavily focused on 30-day “sprints”. This is where the project team breaks down a wishlist of end-goals into small chunks, then works on them in 30-day sessions with daily stand-up meetings. This makes it easy to manage large and complex projects.<\/li>\n
- Fast paced<\/strong>: The “sprint” approach with its 30-day limit and daily stand-up meetings promotes rapid iteration and development.<\/li>\n
- Team-focused<\/strong>: Since the project team is expected to manage itself, Scrum teams have clear visibility into the project. It also means that project leaders can set their own priorities as per their own knowledge of their capabilities.<\/li>\n<\/ol>\n
Besides these, it has all the benefits of Agile – rapid iteration and regular stakeholder feedback.<\/p>\n
<\/a>Disadvantages of Scrum<\/h5>\n\n- Scope creep<\/strong>: Since there is no fixed end-date, nor a project manager for scheduling and budgeting, Scrum can easily lead to scope creep.<\/li>\n
- Higher risk<\/strong>: Since the project team is self-managing, there is a higher risk of failure unless the team is highly disciplined and motivated. If the team doesn’t have enough experience, Scrum has a very high chance of failure.<\/li>\n
- Lack of flexibility<\/strong>: The project-team focus means that any resource leaving the team in-between will hugely impact the net results. This approach is also not flexible enough for large teams.<\/li>\n<\/ol>\n
<\/a>Scrum is best for<\/h5>\nThe Scrum approach is best for highly experienced, disciplined and motivated project teams who can set their own priorities and understand project requirements clearly. It has all the flaws of Agile along with all its benefits. It works for large projects but fails if the project team itself is very large.<\/p>\n
<\/a>Scrum values<\/h5>\nBelow diagram depicts the core values of the Scrum framework.<\/p>\n
\u00a0![\"\"](\"\/wp-content\/uploads\/2019\/01\/scrum3-300x176.png\")
<\/h1>\n<\/a>Commitment<\/h5>\n\n- This is not about the expectation that all scope will be delivered, no matter<\/li>\n
- Commitment is about dedication and applies to actions, the effort, not the final result<\/li>\n
- Maximum possible effort for achieving the goal and will be transparent<\/li>\n
- Commitment towards \u2013\n
\n- Quality<\/li>\n
- Collaboration<\/li>\n
- Learning<\/li>\n
- Professionalism<\/li>\n
- Excellence<\/li>\n
- Self-organize<\/li>\n
- Improvement<\/li>\n
- Transparency<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
<\/a>Focus<\/h5>\n\n- Focus on what is most important now<\/li>\n
- Future is highly uncertain, focus on YAGNI \u2013 \u201cYou aren\u2019t gonna need it\u201d<\/li>\n
- Focus on the simplest thing<\/li>\n<\/ol>\n
<\/a>Openness<\/h5>\n\n- Be transparent, inspect in order to make sensible adaptation<\/li>\n
- Open about our work, progress, problems, and learnings<\/li>\n
- Open for people and working with people<\/li>\n
- Acknowledging people to be people, and not resources, robots or replaceable machinery<\/li>\n
- Open to collaborate with stakeholders and wider environment<\/li>\n
- Open in sharing feedback and learn from one another<\/li>\n
- Open for change<\/li>\n<\/ol>\n
<\/a>Respect<\/h5>\n\n- Respect for people, their experience and their personal background<\/li>\n
- Respect different opinions, we might learn from it<\/li>\n
- Respect for our sponsor by not building features that nobody will use<\/li>\n
- Respect for users by fixing their problems and quality product<\/li>\n
- Respect for wider environment by not behaving as an isolated island in the world<\/li>\n
- Respect each other\u2019s skills and expertise<\/li>\n<\/ol>\n
<\/a>Courage<\/h5>\n\n- Courage to not build features that nobody wants<\/li>\n
- Courage in admitting requirements will never be perfect<\/li>\n
- Courage in admitting that no plan can capture reality and complexity<\/li>\n
- Courage to not deliver undone features<\/li>\n
- Courage to share risks and benefits<\/li>\n
- Courage in sharing information that might help team and the organization<\/li>\n
- Courage to change direction<\/li>\n<\/ol>\n
<\/a>Roles, Artifacts, and Events in the Scrum Framework<\/h5>\nBelow diagram depicts various roles and their correlation in the Scrum framework.<\/p>\n
\u00a0![\"\"](\"\/wp-content\/uploads\/2019\/01\/scrum4-300x146.png\")
<\/strong><\/p>\n<\/a>Roles<\/h5>\nVarious roles that comprise of scrum framework are:<\/p>\n
<\/a>Scrum Master<\/h6>\nA Scrum Master is a team leader and facilitator who helps the team members to follow agile practices so that they can meet their commitments. The Scrum Master is responsible for ensuring Scrum is understood and enacted.<\/p>\n
A Scrum Master serves the Scrum Team<\/p>\n
\n- Lead by example<\/strong>. Be the first one to be vulnerable. Be a living demonstration of team assets and scrum values. Admit your missteps.<\/li>\n
- Create an environment of safety<\/strong>. Encourage debate, support it and keep it productive. Use coaching techniques like open questions.<\/li>\n
- Facilitate Consensus<\/strong>. Try to have key decisions made clear at the end of team discussions, making responsibility and deadlines clear.<\/li>\n
- Learn to read the room<\/strong>. Be connected without being present.<\/li>\n
- Show patience<\/strong>. Be okay with silence. Let the team take action.<\/li>\n
- Restrain from solving<\/strong>. Reveal, not resolve. Be careful not to steer the team towards premature resolution of conflict to protect people. Help team members develop conflict resolution skills.<\/li>\n
- Be comfortable with failure<\/strong>. Team decisions may not lead to the anticipated outcome. This is part of learning and growth.<\/li>\n
- Care for people<\/strong>. Listen to them without judgement. Assume positive intent. Meet them where they are and help them find the next step.<\/li>\n
- Show low tolerance for organizational impediments<\/strong>.<\/li>\n<\/ol>\n
Below diagram depicts the misunderstood stances of a scrum master<\/p>\n
![\"\"](\"\/wp-content\/uploads\/2019\/01\/scrum5-300x171.png\")
<\/p>\n
<\/p>\n
Stances of a scrum master<\/p>\n
![\"\"](\"\/wp-content\/uploads\/2019\/01\/scrum6-300x169.png\")
<\/p>\n
<\/p>\n
Stances of a scrum master are:<\/p>\n
\n- Servant Leader<\/li>\n
- Coach<\/li>\n
- Facilitator<\/li>\n
- Teacher<\/li>\n
- Mentor<\/li>\n
- Manager<\/li>\n
- Impediment Remover<\/li>\n
- Change Agent<\/li>\n<\/ol>\n
Scrum Master as a Servant Leader<\/strong><\/h6>\n\n- Setting up Scrum as a servant process, not a commanding process<\/li>\n
- Guiding the Development Team towards self-organization<\/li>\n
- Leading the team through healthy conflict and debate<\/li>\n
- Shielding the team from disturbance and external threats<\/li>\n
- Helping the team make visible, remove and prevent impediment<\/li>\n
- Creating transparency by radiating information via Scrum events and artifacts<\/li>\n<\/ol>\n
Scrum Master as a Coach<\/strong><\/h6>\n\n- Coaching the Individual in \u2013\n
\n- Focusing on mindset and behavior<\/li>\n
- Using Scrum well<\/li>\n
- Taking next step in his\/her Agile journey<\/li>\n<\/ol>\n<\/li>\n
- Coaching the Team in \u2013\n
\n- Creating a learning culture<\/li>\n
- Changing mindset for continuous improvement<\/li>\n
- Problem solving and conflict resolution<\/li>\n<\/ol>\n<\/li>\n
- Coaching the organization in \u2013\n
\n- Collaborating with the Scrum team<\/li>\n
- Doing product management with a focus on business value<\/li>\n
- Delivering high quality and valuable products<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Facilitator<\/strong><\/h6>\n\n- Facilitate the Scrum framework process and the continuous improvement of the process<\/li>\n
- Facilitate the integration of Scrum team into the wider organization<\/li>\n
- Facilitates the Scrum events to be purposeful and effective\n
\n- Daily Scrum \u2013 an atmosphere where healthy peer pressure occurs on delivering quality, commitment and addressing impediments<\/li>\n
- Sprint Planning \u2013 collaboration between the Development Team and the Product Owner, keeping a strong focus on delivering value<\/li>\n
- Sprint Review \u2013 Scrum team, sponsors and stakeholders collaborate to work as One team with the same purpose<\/li>\n
- Sprint Retrospective \u2013 a safe atmosphere in which \u201celephant in the room\u201d is addressed<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Teacher<\/strong><\/h6>\n\n- Teach Agile during the team start-up<\/li>\n
- Teach the Scrum team about Empiricism<\/li>\n
- Teach about Scrum to Scrum team and other stakeholders<\/li>\n
- Teach the difference between Scrum the Best practices<\/li>\n
- Teach the team about the self-organization<\/li>\n
- Team the team about removing impediments<\/li>\n
- Teach the team about the importance of the product vision<\/li>\n
- Team the team about visualizing progress<\/li>\n
- Teach the Product Owner about Backlog Management<\/li>\n
- Teach the team to have fun<\/li>\n<\/ol>\n
Scrum Master as a Mentor<\/strong><\/h6>\n\n- Shu \u2013 Follow the Rules\n
\n- Scrum Master acts as a teacher<\/li>\n
- Shares knowledge and skills<\/li>\n
- Provide instructions on \u201cHow to do\u201d<\/li>\n<\/ol>\n<\/li>\n
- Ha \u2013 Break the Rules\n
\n- Offers new perspectives and possibilities<\/li>\n<\/ol>\n<\/li>\n
- Ri \u2013 Be the Rule\n
\n- Act as a counsellor<\/li>\n
- Give advice whenever asked for it<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Manager<\/strong><\/h6>\n\n- Manages impediments<\/li>\n
- Manages the process<\/li>\n
- Manages the boundaries of self-organization<\/li>\n
- Manages the team\u2019s health<\/li>\n
- Manages the culture<\/li>\n<\/ol>\n
Scrum Master as a Impediment Remover<\/strong><\/h6>\n\n- Respect the self-organizing capability of the development team<\/li>\n
- Creating environment where Development Team feel safe to raise impediments<\/li>\n
- Understand the meaning of \u201cImpediment\u201d<\/li>\n
- Don\u2019t wait until the Daily Scrum<\/li>\n
- Improve transparency by using the Impediment board<\/li>\n
- Be bold and creative in removing impediments<\/li>\n<\/ol>\n
Scrum Master as a Change Agent<\/strong><\/h6>\n\n- Creating an environment that allows the spirit of Scrum to thrive<\/li>\n
- Leading and coaching the organization in its Scrum framework adoption<\/li>\n
- Helping employees and stakeholders understand and enact Scrum development<\/li>\n
- Causing change that increases the productivity of Scrum Team<\/li>\n
- Working with other Scrum Masters to increase the effectiveness of Scrum in the organization<\/li>\n
- Planning Scrum implementation within the organization<\/li>\n<\/ol>\n
Scrum Master Service to the Product Owner<\/strong><\/h6>\n\n- Finding techniques for effective Product Backlog management.<\/li>\n
- Helping the Scrum Team understand the need for clear and concise Product Backlog items.<\/li>\n
- Understanding product planning in an empirical environment.<\/li>\n
- Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.<\/li>\n
- Understanding and practicing agility.<\/li>\n
- Facilitating Scrum events as requested or needed.<\/li>\n<\/ol>\n
Scrum Master Service to the Development Team<\/strong><\/h6>\n\n- Coaching the Development Team in self-organization and cross-functionality.<\/li>\n
- Helping the Development Team to create high-value products.<\/li>\n
- Removing impediments to the Development Team\u2019s progress.<\/li>\n
- Facilitating Scrum events as requested or needed.<\/li>\n
- Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.<\/li>\n<\/ol>\n
Scrum Master Service to the Organization <\/strong><\/h6>\n\n- Leading and coaching the organization in its Scrum adoption.<\/li>\n
- Planning Scrum implementations within the organization.<\/li>\n
- Helping employees and stakeholders understand and enact Scrum and empirical product development.<\/li>\n
- Causing change that increases the productivity of the Scrum Team.<\/li>\n
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum framework in the organization.<\/li>\n<\/ol>\n
<\/a>Scrum Team<\/h5>\nIt is the team which works for SDLC of the application. This team includes developers, testers, technical lead, product owner and scrum master. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of \u201cDone\u201d product at the end of each Sprint. Only members of the Development Team create the Increment.<\/p>\n
\n- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;<\/li>\n
- Development Teams are cross-functional, with the skills as a team necessary to create a product Increment;<\/li>\n
- Scrum framework recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;<\/li>\n
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing or business analysis; there are no exceptions to this rule.<\/li>\n
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.<\/li>\n<\/ol>\n
<\/a>Product Owner<\/h5>\nA Product Owner drives the product from business perspective and is the one who decides and defines requirements, prioritize their values and release dates. Product owner is also involved in iteration planning and release planning meetings.<\/p>\n
\n- Clearly expressing Product Backlog items;<\/li>\n
- Ordering the items in the Product Backlog to best achieve goals and missions;<\/li>\n
- Optimizing the value of the work the Development Team performs;<\/li>\n
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;<\/li>\n<\/ol>\n
<\/a>Artefacts<\/h5>\n<\/a>Sprint Backlog<\/h5>\n\n- Sprint backlog consists of the selected product backlog items and a plan to deliver them.<\/li>\n
- Selected Product Backlog items are often decomposed.<\/li>\n
- Work for the Sprint emerges.<\/li>\n
- Development team members sign up for work, they aren\u2019t assigned.<\/li>\n
- Development team members may modify the Sprint Backlog anytime, as they see fit.<\/li>\n<\/ol>\n
<\/a>Product Backlog<\/h5>\nThe product backlog is a list of all the product features generally defined by \u201cuser stories\u201d. User stories define everything potential users want to do on the site. There are many tools to keep track of your project backlog, both analogue and digital options.
\nAfter all user stories are created, they are ranked based on the priority and grouping on the stories. Grouping is done based on the inter-dependencies of the stories<\/p>\n
<\/a>Events<\/h5>\n<\/a>Sprint<\/h5>\nAgile projects are broken down into small, consistent time intervals. These intervals are referred to as sprints.
\nSprints are time-boxed iterations that serve iterative-incremental development.<\/p>\n
\n- All development is done within a sprint<\/li>\n
- A Sprint contains the time-boxed scrum events<\/li>\n
- A Sprint is one month or less, and it is best to have a consistent duration\n
\n- Sprint length is determined by acceptable planning horizon<\/li>\n<\/ol>\n<\/li>\n
- Scrum knows no phases, only Sprints\n
\n- No testing, hardening, release, analysis Sprints<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
The entire point of Scrum Framework is to create a Done increment<\/strong><\/h6>\nA sprint has a time duration of 1 – 3 weeks depending on the extent of the overall project. Before each sprint, there is a sprint planning meeting. This meeting determines what the goals are for that sprint. Based on the team velocity, a set of features are pulled from the top of the backlog. During the sprint, no features are added, and the sprint goals don\u2019t change<\/p>\n
<\/a>Sprint Planning<\/h5>\nThis is the first meeting of every sprint and the amount of work which can be achieved in the sprint is decided in this meeting depending on the team velocity. User stories are assigned to the dedicated team as per the requirement and analysis.<\/p>\n
![\"\"](\"\/wp-content\/uploads\/2019\/01\/scrum7-300x190.png\")
<\/p>\n
<\/p>\n
<\/a>Daily Scrum<\/h5>\nEvery morning of the sprint the project team gets together for a short (under 15 minute) meeting. This meeting takes place at the same time every day and includes everyone on the project.<\/p>\n
\n- 15-minute time-box daily event.<\/li>\n
- Consistent place and time.<\/li>\n
- Development team inspects their progress toward the Sprint goal<\/li>\n
- Development team creates a plan for the next 24 hours.<\/li>\n
- Not a problem-solving meeting.<\/li>\n
- Not a status meeting.<\/li>\n<\/ol>\n
Each person on the team is tasked to answer 3 simple questions:<\/p>\n
\n- What did you do yesterday?<\/li>\n
- What you are going to do today?<\/li>\n
- Any blockers or dependencies in your way?<\/li>\n<\/ul>\n
<\/a>Sprint Review\/ Retrospective Meeting<\/h5>\nAt the end of every sprint, A Sprint Retrospective meeting takes place with a functional demo of the user stories that has been completed during the sprint. The sprint review meeting brings together the project team and other project stakeholders like the client to present the work that was completed.<\/p>\n
\n- Scrum Team inspects how the last sprint went\n
\n- People, relationships, process, tools<\/li>\n
- Definition of \u201cDone\u201d<\/li>\n<\/ol>\n<\/li>\n
- Scrum team selects actionable improvements for implementation in next Sprint.<\/li>\n<\/ol>\n
<\/a>Scrum events quick reference<\/h5>\n
\n\n\n\nEvent<\/strong><\/p>\n<\/td>\nInspection<\/strong><\/td>\nAdaptation<\/strong><\/td>\nWho Attends<\/strong><\/td>\n\nTime-box for 1 Month<\/strong><\/p>\n<\/td>\n<\/tr>\n\nSprint Planning<\/strong><\/td>\nProduct Backlog<\/td>\n Sprint Goal, Forecast, Sprint Backlog<\/td>\n Scrum Team<\/td>\n 8 hours<\/td>\n<\/tr>\n \nDaily Scrum<\/strong><\/td>\nProgress toward sprint goal<\/td>\n Sprint Backlog<\/td>\n \nDevelopment Team<\/p>\n<\/td>\n
15-minutes (always)<\/td>\n<\/tr>\n \nSprint Review<\/strong><\/td>\nIncrement, Sprint, Product Backlog<\/td>\n Product Backlog<\/td>\n Scrum Team Stakeholders<\/td>\n 4 hours<\/td>\n<\/tr>\n \nSprint Retrospective<\/strong><\/td>\nSprint<\/td>\n Actionable and committed improvements<\/td>\n Scrum Team<\/td>\n \n3 hours<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
The Scrum approach places the project team in front and center of the project. Often, there is no project manager. Instead, the team is expected to be self-organizing and self-managing. This makes it ideal for highly focused and skilled teams, but not so much for others.<\/p>\n
<\/p>\n
<\/a>Advantages of Scrum<\/h5>\n\n- Scrum “sprints”<\/strong>: The Scrum approach is heavily focused on 30-day “sprints”. This is where the project team breaks down a wishlist of end-goals into small chunks, then works on them in 30-day sessions with daily stand-up meetings. This makes it easy to manage large and complex projects.<\/li>\n
- Fast paced<\/strong>: The “sprint” approach with its 30-day limit and daily stand-up meetings promotes rapid iteration and development.<\/li>\n
- Team-focused<\/strong>: Since the project team is expected to manage itself, Scrum teams have clear visibility into the project. It also means that project leaders can set their own priorities as per their own knowledge of their capabilities.<\/li>\n<\/ol>\n
Besides these, it has all the benefits of Agile – rapid iteration and regular stakeholder feedback.<\/p>\n
<\/a>Disadvantages of Scrum<\/h5>\n\n- Scope creep<\/strong>: Since there is no fixed end-date, nor a project manager for scheduling and budgeting, Scrum can easily lead to scope creep.<\/li>\n
- Higher risk<\/strong>: Since the project team is self-managing, there is a higher risk of failure unless the team is highly disciplined and motivated. If the team doesn’t have enough experience, Scrum has a very high chance of failure.<\/li>\n
- Lack of flexibility<\/strong>: The project-team focus means that any resource leaving the team in-between will hugely impact the net results. This approach is also not flexible enough for large teams.<\/li>\n<\/ol>\n
<\/a>Scrum is best for<\/h5>\nThe Scrum approach is best for highly experienced, disciplined and motivated project teams who can set their own priorities and understand project requirements clearly. It has all the flaws of Agile along with all its benefits. It works for large projects but fails if the project team itself is very large.<\/p>\n
<\/a>Scrum values<\/h5>\nBelow diagram depicts the core values of the Scrum framework.<\/p>\n
\u00a0<\/h1>\n<\/a>Commitment<\/h5>\n\n- This is not about the expectation that all scope will be delivered, no matter<\/li>\n
- Commitment is about dedication and applies to actions, the effort, not the final result<\/li>\n
- Maximum possible effort for achieving the goal and will be transparent<\/li>\n
- Commitment towards \u2013\n
\n- Quality<\/li>\n
- Collaboration<\/li>\n
- Learning<\/li>\n
- Professionalism<\/li>\n
- Excellence<\/li>\n
- Self-organize<\/li>\n
- Improvement<\/li>\n
- Transparency<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
<\/a>Focus<\/h5>\n\n- Focus on what is most important now<\/li>\n
- Future is highly uncertain, focus on YAGNI \u2013 \u201cYou aren\u2019t gonna need it\u201d<\/li>\n
- Focus on the simplest thing<\/li>\n<\/ol>\n
<\/a>Openness<\/h5>\n\n- Be transparent, inspect in order to make sensible adaptation<\/li>\n
- Open about our work, progress, problems, and learnings<\/li>\n
- Open for people and working with people<\/li>\n
- Acknowledging people to be people, and not resources, robots or replaceable machinery<\/li>\n
- Open to collaborate with stakeholders and wider environment<\/li>\n
- Open in sharing feedback and learn from one another<\/li>\n
- Open for change<\/li>\n<\/ol>\n
<\/a>Respect<\/h5>\n\n- Respect for people, their experience and their personal background<\/li>\n
- Respect different opinions, we might learn from it<\/li>\n
- Respect for our sponsor by not building features that nobody will use<\/li>\n
- Respect for users by fixing their problems and quality product<\/li>\n
- Respect for wider environment by not behaving as an isolated island in the world<\/li>\n
- Respect each other\u2019s skills and expertise<\/li>\n<\/ol>\n
<\/a>Courage<\/h5>\n\n- Courage to not build features that nobody wants<\/li>\n
- Courage in admitting requirements will never be perfect<\/li>\n
- Courage in admitting that no plan can capture reality and complexity<\/li>\n
- Courage to not deliver undone features<\/li>\n
- Courage to share risks and benefits<\/li>\n
- Courage in sharing information that might help team and the organization<\/li>\n
- Courage to change direction<\/li>\n<\/ol>\n
<\/a>Roles, Artifacts, and Events in the Scrum Framework<\/h5>\nBelow diagram depicts various roles and their correlation in the Scrum framework.<\/p>\n
\u00a0<\/strong><\/p>\n<\/a>Roles<\/h5>\nVarious roles that comprise of scrum framework are:<\/p>\n
<\/a>Scrum Master<\/h6>\nA Scrum Master is a team leader and facilitator who helps the team members to follow agile practices so that they can meet their commitments. The Scrum Master is responsible for ensuring Scrum is understood and enacted.<\/p>\n
A Scrum Master serves the Scrum Team<\/p>\n
\n- Lead by example<\/strong>. Be the first one to be vulnerable. Be a living demonstration of team assets and scrum values. Admit your missteps.<\/li>\n
- Create an environment of safety<\/strong>. Encourage debate, support it and keep it productive. Use coaching techniques like open questions.<\/li>\n
- Facilitate Consensus<\/strong>. Try to have key decisions made clear at the end of team discussions, making responsibility and deadlines clear.<\/li>\n
- Learn to read the room<\/strong>. Be connected without being present.<\/li>\n
- Show patience<\/strong>. Be okay with silence. Let the team take action.<\/li>\n
- Restrain from solving<\/strong>. Reveal, not resolve. Be careful not to steer the team towards premature resolution of conflict to protect people. Help team members develop conflict resolution skills.<\/li>\n
- Be comfortable with failure<\/strong>. Team decisions may not lead to the anticipated outcome. This is part of learning and growth.<\/li>\n
- Care for people<\/strong>. Listen to them without judgement. Assume positive intent. Meet them where they are and help them find the next step.<\/li>\n
- Show low tolerance for organizational impediments<\/strong>.<\/li>\n<\/ol>\n
Below diagram depicts the misunderstood stances of a scrum master<\/p>\n
<\/p>\n
<\/p>\n
Stances of a scrum master<\/p>\n
<\/p>\n
<\/p>\n
Stances of a scrum master are:<\/p>\n
\n- Servant Leader<\/li>\n
- Coach<\/li>\n
- Facilitator<\/li>\n
- Teacher<\/li>\n
- Mentor<\/li>\n
- Manager<\/li>\n
- Impediment Remover<\/li>\n
- Change Agent<\/li>\n<\/ol>\n
Scrum Master as a Servant Leader<\/strong><\/h6>\n\n- Setting up Scrum as a servant process, not a commanding process<\/li>\n
- Guiding the Development Team towards self-organization<\/li>\n
- Leading the team through healthy conflict and debate<\/li>\n
- Shielding the team from disturbance and external threats<\/li>\n
- Helping the team make visible, remove and prevent impediment<\/li>\n
- Creating transparency by radiating information via Scrum events and artifacts<\/li>\n<\/ol>\n
Scrum Master as a Coach<\/strong><\/h6>\n\n- Coaching the Individual in \u2013\n
\n- Focusing on mindset and behavior<\/li>\n
- Using Scrum well<\/li>\n
- Taking next step in his\/her Agile journey<\/li>\n<\/ol>\n<\/li>\n
- Coaching the Team in \u2013\n
\n- Creating a learning culture<\/li>\n
- Changing mindset for continuous improvement<\/li>\n
- Problem solving and conflict resolution<\/li>\n<\/ol>\n<\/li>\n
- Coaching the organization in \u2013\n
\n- Collaborating with the Scrum team<\/li>\n
- Doing product management with a focus on business value<\/li>\n
- Delivering high quality and valuable products<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Facilitator<\/strong><\/h6>\n\n- Facilitate the Scrum framework process and the continuous improvement of the process<\/li>\n
- Facilitate the integration of Scrum team into the wider organization<\/li>\n
- Facilitates the Scrum events to be purposeful and effective\n
\n- Daily Scrum \u2013 an atmosphere where healthy peer pressure occurs on delivering quality, commitment and addressing impediments<\/li>\n
- Sprint Planning \u2013 collaboration between the Development Team and the Product Owner, keeping a strong focus on delivering value<\/li>\n
- Sprint Review \u2013 Scrum team, sponsors and stakeholders collaborate to work as One team with the same purpose<\/li>\n
- Sprint Retrospective \u2013 a safe atmosphere in which \u201celephant in the room\u201d is addressed<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Teacher<\/strong><\/h6>\n\n- Teach Agile during the team start-up<\/li>\n
- Teach the Scrum team about Empiricism<\/li>\n
- Teach about Scrum to Scrum team and other stakeholders<\/li>\n
- Teach the difference between Scrum the Best practices<\/li>\n
- Teach the team about the self-organization<\/li>\n
- Team the team about removing impediments<\/li>\n
- Teach the team about the importance of the product vision<\/li>\n
- Team the team about visualizing progress<\/li>\n
- Teach the Product Owner about Backlog Management<\/li>\n
- Teach the team to have fun<\/li>\n<\/ol>\n
Scrum Master as a Mentor<\/strong><\/h6>\n\n- Shu \u2013 Follow the Rules\n
\n- Scrum Master acts as a teacher<\/li>\n
- Shares knowledge and skills<\/li>\n
- Provide instructions on \u201cHow to do\u201d<\/li>\n<\/ol>\n<\/li>\n
- Ha \u2013 Break the Rules\n
\n- Offers new perspectives and possibilities<\/li>\n<\/ol>\n<\/li>\n
- Ri \u2013 Be the Rule\n
\n- Act as a counsellor<\/li>\n
- Give advice whenever asked for it<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Manager<\/strong><\/h6>\n\n- Manages impediments<\/li>\n
- Manages the process<\/li>\n
- Manages the boundaries of self-organization<\/li>\n
- Manages the team\u2019s health<\/li>\n
- Manages the culture<\/li>\n<\/ol>\n
Scrum Master as a Impediment Remover<\/strong><\/h6>\n\n- Respect the self-organizing capability of the development team<\/li>\n
- Creating environment where Development Team feel safe to raise impediments<\/li>\n
- Understand the meaning of \u201cImpediment\u201d<\/li>\n
- Don\u2019t wait until the Daily Scrum<\/li>\n
- Improve transparency by using the Impediment board<\/li>\n
- Be bold and creative in removing impediments<\/li>\n<\/ol>\n
Scrum Master as a Change Agent<\/strong><\/h6>\n\n- Creating an environment that allows the spirit of Scrum to thrive<\/li>\n
- Leading and coaching the organization in its Scrum framework adoption<\/li>\n
- Helping employees and stakeholders understand and enact Scrum development<\/li>\n
- Causing change that increases the productivity of Scrum Team<\/li>\n
- Working with other Scrum Masters to increase the effectiveness of Scrum in the organization<\/li>\n
- Planning Scrum implementation within the organization<\/li>\n<\/ol>\n
Scrum Master Service to the Product Owner<\/strong><\/h6>\n\n- Finding techniques for effective Product Backlog management.<\/li>\n
- Helping the Scrum Team understand the need for clear and concise Product Backlog items.<\/li>\n
- Understanding product planning in an empirical environment.<\/li>\n
- Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.<\/li>\n
- Understanding and practicing agility.<\/li>\n
- Facilitating Scrum events as requested or needed.<\/li>\n<\/ol>\n
Scrum Master Service to the Development Team<\/strong><\/h6>\n\n- Coaching the Development Team in self-organization and cross-functionality.<\/li>\n
- Helping the Development Team to create high-value products.<\/li>\n
- Removing impediments to the Development Team\u2019s progress.<\/li>\n
- Facilitating Scrum events as requested or needed.<\/li>\n
- Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.<\/li>\n<\/ol>\n
Scrum Master Service to the Organization <\/strong><\/h6>\n\n- Leading and coaching the organization in its Scrum adoption.<\/li>\n
- Planning Scrum implementations within the organization.<\/li>\n
- Helping employees and stakeholders understand and enact Scrum and empirical product development.<\/li>\n
- Causing change that increases the productivity of the Scrum Team.<\/li>\n
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum framework in the organization.<\/li>\n<\/ol>\n
<\/a>Scrum Team<\/h5>\nIt is the team which works for SDLC of the application. This team includes developers, testers, technical lead, product owner and scrum master. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of \u201cDone\u201d product at the end of each Sprint. Only members of the Development Team create the Increment.<\/p>\n
\n- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;<\/li>\n
- Development Teams are cross-functional, with the skills as a team necessary to create a product Increment;<\/li>\n
- Scrum framework recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;<\/li>\n
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing or business analysis; there are no exceptions to this rule.<\/li>\n
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.<\/li>\n<\/ol>\n
<\/a>Product Owner<\/h5>\nA Product Owner drives the product from business perspective and is the one who decides and defines requirements, prioritize their values and release dates. Product owner is also involved in iteration planning and release planning meetings.<\/p>\n
\n- Clearly expressing Product Backlog items;<\/li>\n
- Ordering the items in the Product Backlog to best achieve goals and missions;<\/li>\n
- Optimizing the value of the work the Development Team performs;<\/li>\n
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;<\/li>\n<\/ol>\n
<\/a>Artefacts<\/h5>\n<\/a>Sprint Backlog<\/h5>\n\n- Sprint backlog consists of the selected product backlog items and a plan to deliver them.<\/li>\n
- Selected Product Backlog items are often decomposed.<\/li>\n
- Work for the Sprint emerges.<\/li>\n
- Development team members sign up for work, they aren\u2019t assigned.<\/li>\n
- Development team members may modify the Sprint Backlog anytime, as they see fit.<\/li>\n<\/ol>\n
<\/a>Product Backlog<\/h5>\nThe product backlog is a list of all the product features generally defined by \u201cuser stories\u201d. User stories define everything potential users want to do on the site. There are many tools to keep track of your project backlog, both analogue and digital options.
\nAfter all user stories are created, they are ranked based on the priority and grouping on the stories. Grouping is done based on the inter-dependencies of the stories<\/p>\n
<\/a>Events<\/h5>\n<\/a>Sprint<\/h5>\nAgile projects are broken down into small, consistent time intervals. These intervals are referred to as sprints.
\nSprints are time-boxed iterations that serve iterative-incremental development.<\/p>\n
\n- All development is done within a sprint<\/li>\n
- A Sprint contains the time-boxed scrum events<\/li>\n
- A Sprint is one month or less, and it is best to have a consistent duration\n
\n- Sprint length is determined by acceptable planning horizon<\/li>\n<\/ol>\n<\/li>\n
- Scrum knows no phases, only Sprints\n
\n- No testing, hardening, release, analysis Sprints<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
The entire point of Scrum Framework is to create a Done increment<\/strong><\/h6>\nA sprint has a time duration of 1 – 3 weeks depending on the extent of the overall project. Before each sprint, there is a sprint planning meeting. This meeting determines what the goals are for that sprint. Based on the team velocity, a set of features are pulled from the top of the backlog. During the sprint, no features are added, and the sprint goals don\u2019t change<\/p>\n
<\/a>Sprint Planning<\/h5>\nThis is the first meeting of every sprint and the amount of work which can be achieved in the sprint is decided in this meeting depending on the team velocity. User stories are assigned to the dedicated team as per the requirement and analysis.<\/p>\n
<\/p>\n
<\/p>\n
<\/a>Daily Scrum<\/h5>\nEvery morning of the sprint the project team gets together for a short (under 15 minute) meeting. This meeting takes place at the same time every day and includes everyone on the project.<\/p>\n
\n- 15-minute time-box daily event.<\/li>\n
- Consistent place and time.<\/li>\n
- Development team inspects their progress toward the Sprint goal<\/li>\n
- Development team creates a plan for the next 24 hours.<\/li>\n
- Not a problem-solving meeting.<\/li>\n
- Not a status meeting.<\/li>\n<\/ol>\n
Each person on the team is tasked to answer 3 simple questions:<\/p>\n
\n- What did you do yesterday?<\/li>\n
- What you are going to do today?<\/li>\n
- Any blockers or dependencies in your way?<\/li>\n<\/ul>\n
<\/a>Sprint Review\/ Retrospective Meeting<\/h5>\nAt the end of every sprint, A Sprint Retrospective meeting takes place with a functional demo of the user stories that has been completed during the sprint. The sprint review meeting brings together the project team and other project stakeholders like the client to present the work that was completed.<\/p>\n
\n- Scrum Team inspects how the last sprint went\n
\n- People, relationships, process, tools<\/li>\n
- Definition of \u201cDone\u201d<\/li>\n<\/ol>\n<\/li>\n
- Scrum team selects actionable improvements for implementation in next Sprint.<\/li>\n<\/ol>\n
<\/a>Scrum events quick reference<\/h5>\n
\n\n\n\nEvent<\/strong><\/p>\n<\/td>\nInspection<\/strong><\/td>\nAdaptation<\/strong><\/td>\nWho Attends<\/strong><\/td>\n\nTime-box for 1 Month<\/strong><\/p>\n<\/td>\n<\/tr>\n\nSprint Planning<\/strong><\/td>\nProduct Backlog<\/td>\n Sprint Goal, Forecast, Sprint Backlog<\/td>\n Scrum Team<\/td>\n 8 hours<\/td>\n<\/tr>\n \nDaily Scrum<\/strong><\/td>\nProgress toward sprint goal<\/td>\n Sprint Backlog<\/td>\n \nDevelopment Team<\/p>\n<\/td>\n
15-minutes (always)<\/td>\n<\/tr>\n \nSprint Review<\/strong><\/td>\nIncrement, Sprint, Product Backlog<\/td>\n Product Backlog<\/td>\n Scrum Team Stakeholders<\/td>\n 4 hours<\/td>\n<\/tr>\n \nSprint Retrospective<\/strong><\/td>\nSprint<\/td>\n Actionable and committed improvements<\/td>\n Scrum Team<\/td>\n \n3 hours<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Besides these, it has all the benefits of Agile – rapid iteration and regular stakeholder feedback.<\/p>\n
<\/a>Disadvantages of Scrum<\/h5>\n\n- Scope creep<\/strong>: Since there is no fixed end-date, nor a project manager for scheduling and budgeting, Scrum can easily lead to scope creep.<\/li>\n
- Higher risk<\/strong>: Since the project team is self-managing, there is a higher risk of failure unless the team is highly disciplined and motivated. If the team doesn’t have enough experience, Scrum has a very high chance of failure.<\/li>\n
- Lack of flexibility<\/strong>: The project-team focus means that any resource leaving the team in-between will hugely impact the net results. This approach is also not flexible enough for large teams.<\/li>\n<\/ol>\n
<\/a>Scrum is best for<\/h5>\nThe Scrum approach is best for highly experienced, disciplined and motivated project teams who can set their own priorities and understand project requirements clearly. It has all the flaws of Agile along with all its benefits. It works for large projects but fails if the project team itself is very large.<\/p>\n
<\/a>Scrum values<\/h5>\nBelow diagram depicts the core values of the Scrum framework.<\/p>\n
\u00a0<\/h1>\n<\/a>Commitment<\/h5>\n\n- This is not about the expectation that all scope will be delivered, no matter<\/li>\n
- Commitment is about dedication and applies to actions, the effort, not the final result<\/li>\n
- Maximum possible effort for achieving the goal and will be transparent<\/li>\n
- Commitment towards \u2013\n
\n- Quality<\/li>\n
- Collaboration<\/li>\n
- Learning<\/li>\n
- Professionalism<\/li>\n
- Excellence<\/li>\n
- Self-organize<\/li>\n
- Improvement<\/li>\n
- Transparency<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
<\/a>Focus<\/h5>\n\n- Focus on what is most important now<\/li>\n
- Future is highly uncertain, focus on YAGNI \u2013 \u201cYou aren\u2019t gonna need it\u201d<\/li>\n
- Focus on the simplest thing<\/li>\n<\/ol>\n
<\/a>Openness<\/h5>\n\n- Be transparent, inspect in order to make sensible adaptation<\/li>\n
- Open about our work, progress, problems, and learnings<\/li>\n
- Open for people and working with people<\/li>\n
- Acknowledging people to be people, and not resources, robots or replaceable machinery<\/li>\n
- Open to collaborate with stakeholders and wider environment<\/li>\n
- Open in sharing feedback and learn from one another<\/li>\n
- Open for change<\/li>\n<\/ol>\n
<\/a>Respect<\/h5>\n\n- Respect for people, their experience and their personal background<\/li>\n
- Respect different opinions, we might learn from it<\/li>\n
- Respect for our sponsor by not building features that nobody will use<\/li>\n
- Respect for users by fixing their problems and quality product<\/li>\n
- Respect for wider environment by not behaving as an isolated island in the world<\/li>\n
- Respect each other\u2019s skills and expertise<\/li>\n<\/ol>\n
<\/a>Courage<\/h5>\n\n- Courage to not build features that nobody wants<\/li>\n
- Courage in admitting requirements will never be perfect<\/li>\n
- Courage in admitting that no plan can capture reality and complexity<\/li>\n
- Courage to not deliver undone features<\/li>\n
- Courage to share risks and benefits<\/li>\n
- Courage in sharing information that might help team and the organization<\/li>\n
- Courage to change direction<\/li>\n<\/ol>\n
<\/a>Roles, Artifacts, and Events in the Scrum Framework<\/h5>\nBelow diagram depicts various roles and their correlation in the Scrum framework.<\/p>\n
\u00a0<\/strong><\/p>\n<\/a>Roles<\/h5>\nVarious roles that comprise of scrum framework are:<\/p>\n
<\/a>Scrum Master<\/h6>\nA Scrum Master is a team leader and facilitator who helps the team members to follow agile practices so that they can meet their commitments. The Scrum Master is responsible for ensuring Scrum is understood and enacted.<\/p>\n
A Scrum Master serves the Scrum Team<\/p>\n
\n- Lead by example<\/strong>. Be the first one to be vulnerable. Be a living demonstration of team assets and scrum values. Admit your missteps.<\/li>\n
- Create an environment of safety<\/strong>. Encourage debate, support it and keep it productive. Use coaching techniques like open questions.<\/li>\n
- Facilitate Consensus<\/strong>. Try to have key decisions made clear at the end of team discussions, making responsibility and deadlines clear.<\/li>\n
- Learn to read the room<\/strong>. Be connected without being present.<\/li>\n
- Show patience<\/strong>. Be okay with silence. Let the team take action.<\/li>\n
- Restrain from solving<\/strong>. Reveal, not resolve. Be careful not to steer the team towards premature resolution of conflict to protect people. Help team members develop conflict resolution skills.<\/li>\n
- Be comfortable with failure<\/strong>. Team decisions may not lead to the anticipated outcome. This is part of learning and growth.<\/li>\n
- Care for people<\/strong>. Listen to them without judgement. Assume positive intent. Meet them where they are and help them find the next step.<\/li>\n
- Show low tolerance for organizational impediments<\/strong>.<\/li>\n<\/ol>\n
Below diagram depicts the misunderstood stances of a scrum master<\/p>\n
<\/p>\n
<\/p>\n
Stances of a scrum master<\/p>\n
<\/p>\n
<\/p>\n
Stances of a scrum master are:<\/p>\n
\n- Servant Leader<\/li>\n
- Coach<\/li>\n
- Facilitator<\/li>\n
- Teacher<\/li>\n
- Mentor<\/li>\n
- Manager<\/li>\n
- Impediment Remover<\/li>\n
- Change Agent<\/li>\n<\/ol>\n
Scrum Master as a Servant Leader<\/strong><\/h6>\n\n- Setting up Scrum as a servant process, not a commanding process<\/li>\n
- Guiding the Development Team towards self-organization<\/li>\n
- Leading the team through healthy conflict and debate<\/li>\n
- Shielding the team from disturbance and external threats<\/li>\n
- Helping the team make visible, remove and prevent impediment<\/li>\n
- Creating transparency by radiating information via Scrum events and artifacts<\/li>\n<\/ol>\n
Scrum Master as a Coach<\/strong><\/h6>\n\n- Coaching the Individual in \u2013\n
\n- Focusing on mindset and behavior<\/li>\n
- Using Scrum well<\/li>\n
- Taking next step in his\/her Agile journey<\/li>\n<\/ol>\n<\/li>\n
- Coaching the Team in \u2013\n
\n- Creating a learning culture<\/li>\n
- Changing mindset for continuous improvement<\/li>\n
- Problem solving and conflict resolution<\/li>\n<\/ol>\n<\/li>\n
- Coaching the organization in \u2013\n
\n- Collaborating with the Scrum team<\/li>\n
- Doing product management with a focus on business value<\/li>\n
- Delivering high quality and valuable products<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Facilitator<\/strong><\/h6>\n\n- Facilitate the Scrum framework process and the continuous improvement of the process<\/li>\n
- Facilitate the integration of Scrum team into the wider organization<\/li>\n
- Facilitates the Scrum events to be purposeful and effective\n
\n- Daily Scrum \u2013 an atmosphere where healthy peer pressure occurs on delivering quality, commitment and addressing impediments<\/li>\n
- Sprint Planning \u2013 collaboration between the Development Team and the Product Owner, keeping a strong focus on delivering value<\/li>\n
- Sprint Review \u2013 Scrum team, sponsors and stakeholders collaborate to work as One team with the same purpose<\/li>\n
- Sprint Retrospective \u2013 a safe atmosphere in which \u201celephant in the room\u201d is addressed<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Teacher<\/strong><\/h6>\n\n- Teach Agile during the team start-up<\/li>\n
- Teach the Scrum team about Empiricism<\/li>\n
- Teach about Scrum to Scrum team and other stakeholders<\/li>\n
- Teach the difference between Scrum the Best practices<\/li>\n
- Teach the team about the self-organization<\/li>\n
- Team the team about removing impediments<\/li>\n
- Teach the team about the importance of the product vision<\/li>\n
- Team the team about visualizing progress<\/li>\n
- Teach the Product Owner about Backlog Management<\/li>\n
- Teach the team to have fun<\/li>\n<\/ol>\n
Scrum Master as a Mentor<\/strong><\/h6>\n\n- Shu \u2013 Follow the Rules\n
\n- Scrum Master acts as a teacher<\/li>\n
- Shares knowledge and skills<\/li>\n
- Provide instructions on \u201cHow to do\u201d<\/li>\n<\/ol>\n<\/li>\n
- Ha \u2013 Break the Rules\n
\n- Offers new perspectives and possibilities<\/li>\n<\/ol>\n<\/li>\n
- Ri \u2013 Be the Rule\n
\n- Act as a counsellor<\/li>\n
- Give advice whenever asked for it<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Manager<\/strong><\/h6>\n\n- Manages impediments<\/li>\n
- Manages the process<\/li>\n
- Manages the boundaries of self-organization<\/li>\n
- Manages the team\u2019s health<\/li>\n
- Manages the culture<\/li>\n<\/ol>\n
Scrum Master as a Impediment Remover<\/strong><\/h6>\n\n- Respect the self-organizing capability of the development team<\/li>\n
- Creating environment where Development Team feel safe to raise impediments<\/li>\n
- Understand the meaning of \u201cImpediment\u201d<\/li>\n
- Don\u2019t wait until the Daily Scrum<\/li>\n
- Improve transparency by using the Impediment board<\/li>\n
- Be bold and creative in removing impediments<\/li>\n<\/ol>\n
Scrum Master as a Change Agent<\/strong><\/h6>\n\n- Creating an environment that allows the spirit of Scrum to thrive<\/li>\n
- Leading and coaching the organization in its Scrum framework adoption<\/li>\n
- Helping employees and stakeholders understand and enact Scrum development<\/li>\n
- Causing change that increases the productivity of Scrum Team<\/li>\n
- Working with other Scrum Masters to increase the effectiveness of Scrum in the organization<\/li>\n
- Planning Scrum implementation within the organization<\/li>\n<\/ol>\n
Scrum Master Service to the Product Owner<\/strong><\/h6>\n\n- Finding techniques for effective Product Backlog management.<\/li>\n
- Helping the Scrum Team understand the need for clear and concise Product Backlog items.<\/li>\n
- Understanding product planning in an empirical environment.<\/li>\n
- Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.<\/li>\n
- Understanding and practicing agility.<\/li>\n
- Facilitating Scrum events as requested or needed.<\/li>\n<\/ol>\n
Scrum Master Service to the Development Team<\/strong><\/h6>\n\n- Coaching the Development Team in self-organization and cross-functionality.<\/li>\n
- Helping the Development Team to create high-value products.<\/li>\n
- Removing impediments to the Development Team\u2019s progress.<\/li>\n
- Facilitating Scrum events as requested or needed.<\/li>\n
- Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.<\/li>\n<\/ol>\n
Scrum Master Service to the Organization <\/strong><\/h6>\n\n- Leading and coaching the organization in its Scrum adoption.<\/li>\n
- Planning Scrum implementations within the organization.<\/li>\n
- Helping employees and stakeholders understand and enact Scrum and empirical product development.<\/li>\n
- Causing change that increases the productivity of the Scrum Team.<\/li>\n
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum framework in the organization.<\/li>\n<\/ol>\n
<\/a>Scrum Team<\/h5>\nIt is the team which works for SDLC of the application. This team includes developers, testers, technical lead, product owner and scrum master. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of \u201cDone\u201d product at the end of each Sprint. Only members of the Development Team create the Increment.<\/p>\n
\n- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;<\/li>\n
- Development Teams are cross-functional, with the skills as a team necessary to create a product Increment;<\/li>\n
- Scrum framework recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;<\/li>\n
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing or business analysis; there are no exceptions to this rule.<\/li>\n
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.<\/li>\n<\/ol>\n
<\/a>Product Owner<\/h5>\nA Product Owner drives the product from business perspective and is the one who decides and defines requirements, prioritize their values and release dates. Product owner is also involved in iteration planning and release planning meetings.<\/p>\n
\n- Clearly expressing Product Backlog items;<\/li>\n
- Ordering the items in the Product Backlog to best achieve goals and missions;<\/li>\n
- Optimizing the value of the work the Development Team performs;<\/li>\n
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;<\/li>\n<\/ol>\n
<\/a>Artefacts<\/h5>\n<\/a>Sprint Backlog<\/h5>\n\n- Sprint backlog consists of the selected product backlog items and a plan to deliver them.<\/li>\n
- Selected Product Backlog items are often decomposed.<\/li>\n
- Work for the Sprint emerges.<\/li>\n
- Development team members sign up for work, they aren\u2019t assigned.<\/li>\n
- Development team members may modify the Sprint Backlog anytime, as they see fit.<\/li>\n<\/ol>\n
<\/a>Product Backlog<\/h5>\nThe product backlog is a list of all the product features generally defined by \u201cuser stories\u201d. User stories define everything potential users want to do on the site. There are many tools to keep track of your project backlog, both analogue and digital options.
\nAfter all user stories are created, they are ranked based on the priority and grouping on the stories. Grouping is done based on the inter-dependencies of the stories<\/p>\n
<\/a>Events<\/h5>\n<\/a>Sprint<\/h5>\nAgile projects are broken down into small, consistent time intervals. These intervals are referred to as sprints.
\nSprints are time-boxed iterations that serve iterative-incremental development.<\/p>\n
\n- All development is done within a sprint<\/li>\n
- A Sprint contains the time-boxed scrum events<\/li>\n
- A Sprint is one month or less, and it is best to have a consistent duration\n
\n- Sprint length is determined by acceptable planning horizon<\/li>\n<\/ol>\n<\/li>\n
- Scrum knows no phases, only Sprints\n
\n- No testing, hardening, release, analysis Sprints<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
The entire point of Scrum Framework is to create a Done increment<\/strong><\/h6>\nA sprint has a time duration of 1 – 3 weeks depending on the extent of the overall project. Before each sprint, there is a sprint planning meeting. This meeting determines what the goals are for that sprint. Based on the team velocity, a set of features are pulled from the top of the backlog. During the sprint, no features are added, and the sprint goals don\u2019t change<\/p>\n
<\/a>Sprint Planning<\/h5>\nThis is the first meeting of every sprint and the amount of work which can be achieved in the sprint is decided in this meeting depending on the team velocity. User stories are assigned to the dedicated team as per the requirement and analysis.<\/p>\n
<\/p>\n
<\/p>\n
<\/a>Daily Scrum<\/h5>\nEvery morning of the sprint the project team gets together for a short (under 15 minute) meeting. This meeting takes place at the same time every day and includes everyone on the project.<\/p>\n
\n- 15-minute time-box daily event.<\/li>\n
- Consistent place and time.<\/li>\n
- Development team inspects their progress toward the Sprint goal<\/li>\n
- Development team creates a plan for the next 24 hours.<\/li>\n
- Not a problem-solving meeting.<\/li>\n
- Not a status meeting.<\/li>\n<\/ol>\n
Each person on the team is tasked to answer 3 simple questions:<\/p>\n
\n- What did you do yesterday?<\/li>\n
- What you are going to do today?<\/li>\n
- Any blockers or dependencies in your way?<\/li>\n<\/ul>\n
<\/a>Sprint Review\/ Retrospective Meeting<\/h5>\nAt the end of every sprint, A Sprint Retrospective meeting takes place with a functional demo of the user stories that has been completed during the sprint. The sprint review meeting brings together the project team and other project stakeholders like the client to present the work that was completed.<\/p>\n
\n- Scrum Team inspects how the last sprint went\n
\n- People, relationships, process, tools<\/li>\n
- Definition of \u201cDone\u201d<\/li>\n<\/ol>\n<\/li>\n
- Scrum team selects actionable improvements for implementation in next Sprint.<\/li>\n<\/ol>\n
<\/a>Scrum events quick reference<\/h5>\n
\n\n\n\nEvent<\/strong><\/p>\n<\/td>\nInspection<\/strong><\/td>\nAdaptation<\/strong><\/td>\nWho Attends<\/strong><\/td>\n\nTime-box for 1 Month<\/strong><\/p>\n<\/td>\n<\/tr>\n\nSprint Planning<\/strong><\/td>\nProduct Backlog<\/td>\n Sprint Goal, Forecast, Sprint Backlog<\/td>\n Scrum Team<\/td>\n 8 hours<\/td>\n<\/tr>\n \nDaily Scrum<\/strong><\/td>\nProgress toward sprint goal<\/td>\n Sprint Backlog<\/td>\n \nDevelopment Team<\/p>\n<\/td>\n
15-minutes (always)<\/td>\n<\/tr>\n \nSprint Review<\/strong><\/td>\nIncrement, Sprint, Product Backlog<\/td>\n Product Backlog<\/td>\n Scrum Team Stakeholders<\/td>\n 4 hours<\/td>\n<\/tr>\n \nSprint Retrospective<\/strong><\/td>\nSprint<\/td>\n Actionable and committed improvements<\/td>\n Scrum Team<\/td>\n \n3 hours<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
<\/a>Scrum is best for<\/h5>\nThe Scrum approach is best for highly experienced, disciplined and motivated project teams who can set their own priorities and understand project requirements clearly. It has all the flaws of Agile along with all its benefits. It works for large projects but fails if the project team itself is very large.<\/p>\n
<\/a>Scrum values<\/h5>\nBelow diagram depicts the core values of the Scrum framework.<\/p>\n
\u00a0<\/h1>\n<\/a>Commitment<\/h5>\n\n- This is not about the expectation that all scope will be delivered, no matter<\/li>\n
- Commitment is about dedication and applies to actions, the effort, not the final result<\/li>\n
- Maximum possible effort for achieving the goal and will be transparent<\/li>\n
- Commitment towards \u2013\n
\n- Quality<\/li>\n
- Collaboration<\/li>\n
- Learning<\/li>\n
- Professionalism<\/li>\n
- Excellence<\/li>\n
- Self-organize<\/li>\n
- Improvement<\/li>\n
- Transparency<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
<\/a>Focus<\/h5>\n\n- Focus on what is most important now<\/li>\n
- Future is highly uncertain, focus on YAGNI \u2013 \u201cYou aren\u2019t gonna need it\u201d<\/li>\n
- Focus on the simplest thing<\/li>\n<\/ol>\n
<\/a>Openness<\/h5>\n\n- Be transparent, inspect in order to make sensible adaptation<\/li>\n
- Open about our work, progress, problems, and learnings<\/li>\n
- Open for people and working with people<\/li>\n
- Acknowledging people to be people, and not resources, robots or replaceable machinery<\/li>\n
- Open to collaborate with stakeholders and wider environment<\/li>\n
- Open in sharing feedback and learn from one another<\/li>\n
- Open for change<\/li>\n<\/ol>\n
<\/a>Respect<\/h5>\n\n- Respect for people, their experience and their personal background<\/li>\n
- Respect different opinions, we might learn from it<\/li>\n
- Respect for our sponsor by not building features that nobody will use<\/li>\n
- Respect for users by fixing their problems and quality product<\/li>\n
- Respect for wider environment by not behaving as an isolated island in the world<\/li>\n
- Respect each other\u2019s skills and expertise<\/li>\n<\/ol>\n
<\/a>Courage<\/h5>\n\n- Courage to not build features that nobody wants<\/li>\n
- Courage in admitting requirements will never be perfect<\/li>\n
- Courage in admitting that no plan can capture reality and complexity<\/li>\n
- Courage to not deliver undone features<\/li>\n
- Courage to share risks and benefits<\/li>\n
- Courage in sharing information that might help team and the organization<\/li>\n
- Courage to change direction<\/li>\n<\/ol>\n
<\/a>Roles, Artifacts, and Events in the Scrum Framework<\/h5>\nBelow diagram depicts various roles and their correlation in the Scrum framework.<\/p>\n
\u00a0<\/strong><\/p>\n<\/a>Roles<\/h5>\nVarious roles that comprise of scrum framework are:<\/p>\n
<\/a>Scrum Master<\/h6>\nA Scrum Master is a team leader and facilitator who helps the team members to follow agile practices so that they can meet their commitments. The Scrum Master is responsible for ensuring Scrum is understood and enacted.<\/p>\n
A Scrum Master serves the Scrum Team<\/p>\n
\n- Lead by example<\/strong>. Be the first one to be vulnerable. Be a living demonstration of team assets and scrum values. Admit your missteps.<\/li>\n
- Create an environment of safety<\/strong>. Encourage debate, support it and keep it productive. Use coaching techniques like open questions.<\/li>\n
- Facilitate Consensus<\/strong>. Try to have key decisions made clear at the end of team discussions, making responsibility and deadlines clear.<\/li>\n
- Learn to read the room<\/strong>. Be connected without being present.<\/li>\n
- Show patience<\/strong>. Be okay with silence. Let the team take action.<\/li>\n
- Restrain from solving<\/strong>. Reveal, not resolve. Be careful not to steer the team towards premature resolution of conflict to protect people. Help team members develop conflict resolution skills.<\/li>\n
- Be comfortable with failure<\/strong>. Team decisions may not lead to the anticipated outcome. This is part of learning and growth.<\/li>\n
- Care for people<\/strong>. Listen to them without judgement. Assume positive intent. Meet them where they are and help them find the next step.<\/li>\n
- Show low tolerance for organizational impediments<\/strong>.<\/li>\n<\/ol>\n
Below diagram depicts the misunderstood stances of a scrum master<\/p>\n
<\/p>\n
<\/p>\n
Stances of a scrum master<\/p>\n
<\/p>\n
<\/p>\n
Stances of a scrum master are:<\/p>\n
\n- Servant Leader<\/li>\n
- Coach<\/li>\n
- Facilitator<\/li>\n
- Teacher<\/li>\n
- Mentor<\/li>\n
- Manager<\/li>\n
- Impediment Remover<\/li>\n
- Change Agent<\/li>\n<\/ol>\n
Scrum Master as a Servant Leader<\/strong><\/h6>\n\n- Setting up Scrum as a servant process, not a commanding process<\/li>\n
- Guiding the Development Team towards self-organization<\/li>\n
- Leading the team through healthy conflict and debate<\/li>\n
- Shielding the team from disturbance and external threats<\/li>\n
- Helping the team make visible, remove and prevent impediment<\/li>\n
- Creating transparency by radiating information via Scrum events and artifacts<\/li>\n<\/ol>\n
Scrum Master as a Coach<\/strong><\/h6>\n\n- Coaching the Individual in \u2013\n
\n- Focusing on mindset and behavior<\/li>\n
- Using Scrum well<\/li>\n
- Taking next step in his\/her Agile journey<\/li>\n<\/ol>\n<\/li>\n
- Coaching the Team in \u2013\n
\n- Creating a learning culture<\/li>\n
- Changing mindset for continuous improvement<\/li>\n
- Problem solving and conflict resolution<\/li>\n<\/ol>\n<\/li>\n
- Coaching the organization in \u2013\n
\n- Collaborating with the Scrum team<\/li>\n
- Doing product management with a focus on business value<\/li>\n
- Delivering high quality and valuable products<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Facilitator<\/strong><\/h6>\n\n- Facilitate the Scrum framework process and the continuous improvement of the process<\/li>\n
- Facilitate the integration of Scrum team into the wider organization<\/li>\n
- Facilitates the Scrum events to be purposeful and effective\n
\n- Daily Scrum \u2013 an atmosphere where healthy peer pressure occurs on delivering quality, commitment and addressing impediments<\/li>\n
- Sprint Planning \u2013 collaboration between the Development Team and the Product Owner, keeping a strong focus on delivering value<\/li>\n
- Sprint Review \u2013 Scrum team, sponsors and stakeholders collaborate to work as One team with the same purpose<\/li>\n
- Sprint Retrospective \u2013 a safe atmosphere in which \u201celephant in the room\u201d is addressed<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Teacher<\/strong><\/h6>\n\n- Teach Agile during the team start-up<\/li>\n
- Teach the Scrum team about Empiricism<\/li>\n
- Teach about Scrum to Scrum team and other stakeholders<\/li>\n
- Teach the difference between Scrum the Best practices<\/li>\n
- Teach the team about the self-organization<\/li>\n
- Team the team about removing impediments<\/li>\n
- Teach the team about the importance of the product vision<\/li>\n
- Team the team about visualizing progress<\/li>\n
- Teach the Product Owner about Backlog Management<\/li>\n
- Teach the team to have fun<\/li>\n<\/ol>\n
Scrum Master as a Mentor<\/strong><\/h6>\n\n- Shu \u2013 Follow the Rules\n
\n- Scrum Master acts as a teacher<\/li>\n
- Shares knowledge and skills<\/li>\n
- Provide instructions on \u201cHow to do\u201d<\/li>\n<\/ol>\n<\/li>\n
- Ha \u2013 Break the Rules\n
\n- Offers new perspectives and possibilities<\/li>\n<\/ol>\n<\/li>\n
- Ri \u2013 Be the Rule\n
\n- Act as a counsellor<\/li>\n
- Give advice whenever asked for it<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Manager<\/strong><\/h6>\n\n- Manages impediments<\/li>\n
- Manages the process<\/li>\n
- Manages the boundaries of self-organization<\/li>\n
- Manages the team\u2019s health<\/li>\n
- Manages the culture<\/li>\n<\/ol>\n
Scrum Master as a Impediment Remover<\/strong><\/h6>\n\n- Respect the self-organizing capability of the development team<\/li>\n
- Creating environment where Development Team feel safe to raise impediments<\/li>\n
- Understand the meaning of \u201cImpediment\u201d<\/li>\n
- Don\u2019t wait until the Daily Scrum<\/li>\n
- Improve transparency by using the Impediment board<\/li>\n
- Be bold and creative in removing impediments<\/li>\n<\/ol>\n
Scrum Master as a Change Agent<\/strong><\/h6>\n\n- Creating an environment that allows the spirit of Scrum to thrive<\/li>\n
- Leading and coaching the organization in its Scrum framework adoption<\/li>\n
- Helping employees and stakeholders understand and enact Scrum development<\/li>\n
- Causing change that increases the productivity of Scrum Team<\/li>\n
- Working with other Scrum Masters to increase the effectiveness of Scrum in the organization<\/li>\n
- Planning Scrum implementation within the organization<\/li>\n<\/ol>\n
Scrum Master Service to the Product Owner<\/strong><\/h6>\n\n- Finding techniques for effective Product Backlog management.<\/li>\n
- Helping the Scrum Team understand the need for clear and concise Product Backlog items.<\/li>\n
- Understanding product planning in an empirical environment.<\/li>\n
- Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.<\/li>\n
- Understanding and practicing agility.<\/li>\n
- Facilitating Scrum events as requested or needed.<\/li>\n<\/ol>\n
Scrum Master Service to the Development Team<\/strong><\/h6>\n\n- Coaching the Development Team in self-organization and cross-functionality.<\/li>\n
- Helping the Development Team to create high-value products.<\/li>\n
- Removing impediments to the Development Team\u2019s progress.<\/li>\n
- Facilitating Scrum events as requested or needed.<\/li>\n
- Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.<\/li>\n<\/ol>\n
Scrum Master Service to the Organization <\/strong><\/h6>\n\n- Leading and coaching the organization in its Scrum adoption.<\/li>\n
- Planning Scrum implementations within the organization.<\/li>\n
- Helping employees and stakeholders understand and enact Scrum and empirical product development.<\/li>\n
- Causing change that increases the productivity of the Scrum Team.<\/li>\n
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum framework in the organization.<\/li>\n<\/ol>\n
<\/a>Scrum Team<\/h5>\nIt is the team which works for SDLC of the application. This team includes developers, testers, technical lead, product owner and scrum master. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of \u201cDone\u201d product at the end of each Sprint. Only members of the Development Team create the Increment.<\/p>\n
\n- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;<\/li>\n
- Development Teams are cross-functional, with the skills as a team necessary to create a product Increment;<\/li>\n
- Scrum framework recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;<\/li>\n
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing or business analysis; there are no exceptions to this rule.<\/li>\n
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.<\/li>\n<\/ol>\n
<\/a>Product Owner<\/h5>\nA Product Owner drives the product from business perspective and is the one who decides and defines requirements, prioritize their values and release dates. Product owner is also involved in iteration planning and release planning meetings.<\/p>\n
\n- Clearly expressing Product Backlog items;<\/li>\n
- Ordering the items in the Product Backlog to best achieve goals and missions;<\/li>\n
- Optimizing the value of the work the Development Team performs;<\/li>\n
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;<\/li>\n<\/ol>\n
<\/a>Artefacts<\/h5>\n<\/a>Sprint Backlog<\/h5>\n\n- Sprint backlog consists of the selected product backlog items and a plan to deliver them.<\/li>\n
- Selected Product Backlog items are often decomposed.<\/li>\n
- Work for the Sprint emerges.<\/li>\n
- Development team members sign up for work, they aren\u2019t assigned.<\/li>\n
- Development team members may modify the Sprint Backlog anytime, as they see fit.<\/li>\n<\/ol>\n
<\/a>Product Backlog<\/h5>\nThe product backlog is a list of all the product features generally defined by \u201cuser stories\u201d. User stories define everything potential users want to do on the site. There are many tools to keep track of your project backlog, both analogue and digital options.
\nAfter all user stories are created, they are ranked based on the priority and grouping on the stories. Grouping is done based on the inter-dependencies of the stories<\/p>\n
<\/a>Events<\/h5>\n<\/a>Sprint<\/h5>\nAgile projects are broken down into small, consistent time intervals. These intervals are referred to as sprints.
\nSprints are time-boxed iterations that serve iterative-incremental development.<\/p>\n
\n- All development is done within a sprint<\/li>\n
- A Sprint contains the time-boxed scrum events<\/li>\n
- A Sprint is one month or less, and it is best to have a consistent duration\n
\n- Sprint length is determined by acceptable planning horizon<\/li>\n<\/ol>\n<\/li>\n
- Scrum knows no phases, only Sprints\n
\n- No testing, hardening, release, analysis Sprints<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
The entire point of Scrum Framework is to create a Done increment<\/strong><\/h6>\nA sprint has a time duration of 1 – 3 weeks depending on the extent of the overall project. Before each sprint, there is a sprint planning meeting. This meeting determines what the goals are for that sprint. Based on the team velocity, a set of features are pulled from the top of the backlog. During the sprint, no features are added, and the sprint goals don\u2019t change<\/p>\n
<\/a>Sprint Planning<\/h5>\nThis is the first meeting of every sprint and the amount of work which can be achieved in the sprint is decided in this meeting depending on the team velocity. User stories are assigned to the dedicated team as per the requirement and analysis.<\/p>\n
<\/p>\n
<\/p>\n
<\/a>Daily Scrum<\/h5>\nEvery morning of the sprint the project team gets together for a short (under 15 minute) meeting. This meeting takes place at the same time every day and includes everyone on the project.<\/p>\n
\n- 15-minute time-box daily event.<\/li>\n
- Consistent place and time.<\/li>\n
- Development team inspects their progress toward the Sprint goal<\/li>\n
- Development team creates a plan for the next 24 hours.<\/li>\n
- Not a problem-solving meeting.<\/li>\n
- Not a status meeting.<\/li>\n<\/ol>\n
Each person on the team is tasked to answer 3 simple questions:<\/p>\n
\n- What did you do yesterday?<\/li>\n
- What you are going to do today?<\/li>\n
- Any blockers or dependencies in your way?<\/li>\n<\/ul>\n
<\/a>Sprint Review\/ Retrospective Meeting<\/h5>\nAt the end of every sprint, A Sprint Retrospective meeting takes place with a functional demo of the user stories that has been completed during the sprint. The sprint review meeting brings together the project team and other project stakeholders like the client to present the work that was completed.<\/p>\n
\n- Scrum Team inspects how the last sprint went\n
\n- People, relationships, process, tools<\/li>\n
- Definition of \u201cDone\u201d<\/li>\n<\/ol>\n<\/li>\n
- Scrum team selects actionable improvements for implementation in next Sprint.<\/li>\n<\/ol>\n
<\/a>Scrum events quick reference<\/h5>\n
\n\n\n\nEvent<\/strong><\/p>\n<\/td>\nInspection<\/strong><\/td>\nAdaptation<\/strong><\/td>\nWho Attends<\/strong><\/td>\n\nTime-box for 1 Month<\/strong><\/p>\n<\/td>\n<\/tr>\n\nSprint Planning<\/strong><\/td>\nProduct Backlog<\/td>\n Sprint Goal, Forecast, Sprint Backlog<\/td>\n Scrum Team<\/td>\n 8 hours<\/td>\n<\/tr>\n \nDaily Scrum<\/strong><\/td>\nProgress toward sprint goal<\/td>\n Sprint Backlog<\/td>\n \nDevelopment Team<\/p>\n<\/td>\n
15-minutes (always)<\/td>\n<\/tr>\n \nSprint Review<\/strong><\/td>\nIncrement, Sprint, Product Backlog<\/td>\n Product Backlog<\/td>\n Scrum Team Stakeholders<\/td>\n 4 hours<\/td>\n<\/tr>\n \nSprint Retrospective<\/strong><\/td>\nSprint<\/td>\n Actionable and committed improvements<\/td>\n Scrum Team<\/td>\n \n3 hours<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Below diagram depicts the core values of the Scrum framework.<\/p>\n
\u00a0<\/h1>\n<\/a>Commitment<\/h5>\n\n- This is not about the expectation that all scope will be delivered, no matter<\/li>\n
- Commitment is about dedication and applies to actions, the effort, not the final result<\/li>\n
- Maximum possible effort for achieving the goal and will be transparent<\/li>\n
- Commitment towards \u2013\n
\n- Quality<\/li>\n
- Collaboration<\/li>\n
- Learning<\/li>\n
- Professionalism<\/li>\n
- Excellence<\/li>\n
- Self-organize<\/li>\n
- Improvement<\/li>\n
- Transparency<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
<\/a>Focus<\/h5>\n\n- Focus on what is most important now<\/li>\n
- Future is highly uncertain, focus on YAGNI \u2013 \u201cYou aren\u2019t gonna need it\u201d<\/li>\n
- Focus on the simplest thing<\/li>\n<\/ol>\n
<\/a>Openness<\/h5>\n\n- Be transparent, inspect in order to make sensible adaptation<\/li>\n
- Open about our work, progress, problems, and learnings<\/li>\n
- Open for people and working with people<\/li>\n
- Acknowledging people to be people, and not resources, robots or replaceable machinery<\/li>\n
- Open to collaborate with stakeholders and wider environment<\/li>\n
- Open in sharing feedback and learn from one another<\/li>\n
- Open for change<\/li>\n<\/ol>\n
<\/a>Respect<\/h5>\n\n- Respect for people, their experience and their personal background<\/li>\n
- Respect different opinions, we might learn from it<\/li>\n
- Respect for our sponsor by not building features that nobody will use<\/li>\n
- Respect for users by fixing their problems and quality product<\/li>\n
- Respect for wider environment by not behaving as an isolated island in the world<\/li>\n
- Respect each other\u2019s skills and expertise<\/li>\n<\/ol>\n
<\/a>Courage<\/h5>\n\n- Courage to not build features that nobody wants<\/li>\n
- Courage in admitting requirements will never be perfect<\/li>\n
- Courage in admitting that no plan can capture reality and complexity<\/li>\n
- Courage to not deliver undone features<\/li>\n
- Courage to share risks and benefits<\/li>\n
- Courage in sharing information that might help team and the organization<\/li>\n
- Courage to change direction<\/li>\n<\/ol>\n
<\/a>Roles, Artifacts, and Events in the Scrum Framework<\/h5>\nBelow diagram depicts various roles and their correlation in the Scrum framework.<\/p>\n
\u00a0<\/strong><\/p>\n<\/a>Roles<\/h5>\nVarious roles that comprise of scrum framework are:<\/p>\n
<\/a>Scrum Master<\/h6>\nA Scrum Master is a team leader and facilitator who helps the team members to follow agile practices so that they can meet their commitments. The Scrum Master is responsible for ensuring Scrum is understood and enacted.<\/p>\n
A Scrum Master serves the Scrum Team<\/p>\n
\n- Lead by example<\/strong>. Be the first one to be vulnerable. Be a living demonstration of team assets and scrum values. Admit your missteps.<\/li>\n
- Create an environment of safety<\/strong>. Encourage debate, support it and keep it productive. Use coaching techniques like open questions.<\/li>\n
- Facilitate Consensus<\/strong>. Try to have key decisions made clear at the end of team discussions, making responsibility and deadlines clear.<\/li>\n
- Learn to read the room<\/strong>. Be connected without being present.<\/li>\n
- Show patience<\/strong>. Be okay with silence. Let the team take action.<\/li>\n
- Restrain from solving<\/strong>. Reveal, not resolve. Be careful not to steer the team towards premature resolution of conflict to protect people. Help team members develop conflict resolution skills.<\/li>\n
- Be comfortable with failure<\/strong>. Team decisions may not lead to the anticipated outcome. This is part of learning and growth.<\/li>\n
- Care for people<\/strong>. Listen to them without judgement. Assume positive intent. Meet them where they are and help them find the next step.<\/li>\n
- Show low tolerance for organizational impediments<\/strong>.<\/li>\n<\/ol>\n
Below diagram depicts the misunderstood stances of a scrum master<\/p>\n
<\/p>\n
<\/p>\n
Stances of a scrum master<\/p>\n
<\/p>\n
<\/p>\n
Stances of a scrum master are:<\/p>\n
\n- Servant Leader<\/li>\n
- Coach<\/li>\n
- Facilitator<\/li>\n
- Teacher<\/li>\n
- Mentor<\/li>\n
- Manager<\/li>\n
- Impediment Remover<\/li>\n
- Change Agent<\/li>\n<\/ol>\n
Scrum Master as a Servant Leader<\/strong><\/h6>\n\n- Setting up Scrum as a servant process, not a commanding process<\/li>\n
- Guiding the Development Team towards self-organization<\/li>\n
- Leading the team through healthy conflict and debate<\/li>\n
- Shielding the team from disturbance and external threats<\/li>\n
- Helping the team make visible, remove and prevent impediment<\/li>\n
- Creating transparency by radiating information via Scrum events and artifacts<\/li>\n<\/ol>\n
Scrum Master as a Coach<\/strong><\/h6>\n\n- Coaching the Individual in \u2013\n
\n- Focusing on mindset and behavior<\/li>\n
- Using Scrum well<\/li>\n
- Taking next step in his\/her Agile journey<\/li>\n<\/ol>\n<\/li>\n
- Coaching the Team in \u2013\n
\n- Creating a learning culture<\/li>\n
- Changing mindset for continuous improvement<\/li>\n
- Problem solving and conflict resolution<\/li>\n<\/ol>\n<\/li>\n
- Coaching the organization in \u2013\n
\n- Collaborating with the Scrum team<\/li>\n
- Doing product management with a focus on business value<\/li>\n
- Delivering high quality and valuable products<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Facilitator<\/strong><\/h6>\n\n- Facilitate the Scrum framework process and the continuous improvement of the process<\/li>\n
- Facilitate the integration of Scrum team into the wider organization<\/li>\n
- Facilitates the Scrum events to be purposeful and effective\n
\n- Daily Scrum \u2013 an atmosphere where healthy peer pressure occurs on delivering quality, commitment and addressing impediments<\/li>\n
- Sprint Planning \u2013 collaboration between the Development Team and the Product Owner, keeping a strong focus on delivering value<\/li>\n
- Sprint Review \u2013 Scrum team, sponsors and stakeholders collaborate to work as One team with the same purpose<\/li>\n
- Sprint Retrospective \u2013 a safe atmosphere in which \u201celephant in the room\u201d is addressed<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Teacher<\/strong><\/h6>\n\n- Teach Agile during the team start-up<\/li>\n
- Teach the Scrum team about Empiricism<\/li>\n
- Teach about Scrum to Scrum team and other stakeholders<\/li>\n
- Teach the difference between Scrum the Best practices<\/li>\n
- Teach the team about the self-organization<\/li>\n
- Team the team about removing impediments<\/li>\n
- Teach the team about the importance of the product vision<\/li>\n
- Team the team about visualizing progress<\/li>\n
- Teach the Product Owner about Backlog Management<\/li>\n
- Teach the team to have fun<\/li>\n<\/ol>\n
Scrum Master as a Mentor<\/strong><\/h6>\n\n- Shu \u2013 Follow the Rules\n
\n- Scrum Master acts as a teacher<\/li>\n
- Shares knowledge and skills<\/li>\n
- Provide instructions on \u201cHow to do\u201d<\/li>\n<\/ol>\n<\/li>\n
- Ha \u2013 Break the Rules\n
\n- Offers new perspectives and possibilities<\/li>\n<\/ol>\n<\/li>\n
- Ri \u2013 Be the Rule\n
\n- Act as a counsellor<\/li>\n
- Give advice whenever asked for it<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Manager<\/strong><\/h6>\n\n- Manages impediments<\/li>\n
- Manages the process<\/li>\n
- Manages the boundaries of self-organization<\/li>\n
- Manages the team\u2019s health<\/li>\n
- Manages the culture<\/li>\n<\/ol>\n
Scrum Master as a Impediment Remover<\/strong><\/h6>\n\n- Respect the self-organizing capability of the development team<\/li>\n
- Creating environment where Development Team feel safe to raise impediments<\/li>\n
- Understand the meaning of \u201cImpediment\u201d<\/li>\n
- Don\u2019t wait until the Daily Scrum<\/li>\n
- Improve transparency by using the Impediment board<\/li>\n
- Be bold and creative in removing impediments<\/li>\n<\/ol>\n
Scrum Master as a Change Agent<\/strong><\/h6>\n\n- Creating an environment that allows the spirit of Scrum to thrive<\/li>\n
- Leading and coaching the organization in its Scrum framework adoption<\/li>\n
- Helping employees and stakeholders understand and enact Scrum development<\/li>\n
- Causing change that increases the productivity of Scrum Team<\/li>\n
- Working with other Scrum Masters to increase the effectiveness of Scrum in the organization<\/li>\n
- Planning Scrum implementation within the organization<\/li>\n<\/ol>\n
Scrum Master Service to the Product Owner<\/strong><\/h6>\n\n- Finding techniques for effective Product Backlog management.<\/li>\n
- Helping the Scrum Team understand the need for clear and concise Product Backlog items.<\/li>\n
- Understanding product planning in an empirical environment.<\/li>\n
- Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.<\/li>\n
- Understanding and practicing agility.<\/li>\n
- Facilitating Scrum events as requested or needed.<\/li>\n<\/ol>\n
Scrum Master Service to the Development Team<\/strong><\/h6>\n\n- Coaching the Development Team in self-organization and cross-functionality.<\/li>\n
- Helping the Development Team to create high-value products.<\/li>\n
- Removing impediments to the Development Team\u2019s progress.<\/li>\n
- Facilitating Scrum events as requested or needed.<\/li>\n
- Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.<\/li>\n<\/ol>\n
Scrum Master Service to the Organization <\/strong><\/h6>\n\n- Leading and coaching the organization in its Scrum adoption.<\/li>\n
- Planning Scrum implementations within the organization.<\/li>\n
- Helping employees and stakeholders understand and enact Scrum and empirical product development.<\/li>\n
- Causing change that increases the productivity of the Scrum Team.<\/li>\n
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum framework in the organization.<\/li>\n<\/ol>\n
<\/a>Scrum Team<\/h5>\nIt is the team which works for SDLC of the application. This team includes developers, testers, technical lead, product owner and scrum master. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of \u201cDone\u201d product at the end of each Sprint. Only members of the Development Team create the Increment.<\/p>\n
\n- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;<\/li>\n
- Development Teams are cross-functional, with the skills as a team necessary to create a product Increment;<\/li>\n
- Scrum framework recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;<\/li>\n
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing or business analysis; there are no exceptions to this rule.<\/li>\n
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.<\/li>\n<\/ol>\n
<\/a>Product Owner<\/h5>\nA Product Owner drives the product from business perspective and is the one who decides and defines requirements, prioritize their values and release dates. Product owner is also involved in iteration planning and release planning meetings.<\/p>\n
\n- Clearly expressing Product Backlog items;<\/li>\n
- Ordering the items in the Product Backlog to best achieve goals and missions;<\/li>\n
- Optimizing the value of the work the Development Team performs;<\/li>\n
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;<\/li>\n<\/ol>\n
<\/a>Artefacts<\/h5>\n<\/a>Sprint Backlog<\/h5>\n\n- Sprint backlog consists of the selected product backlog items and a plan to deliver them.<\/li>\n
- Selected Product Backlog items are often decomposed.<\/li>\n
- Work for the Sprint emerges.<\/li>\n
- Development team members sign up for work, they aren\u2019t assigned.<\/li>\n
- Development team members may modify the Sprint Backlog anytime, as they see fit.<\/li>\n<\/ol>\n
<\/a>Product Backlog<\/h5>\nThe product backlog is a list of all the product features generally defined by \u201cuser stories\u201d. User stories define everything potential users want to do on the site. There are many tools to keep track of your project backlog, both analogue and digital options.
\nAfter all user stories are created, they are ranked based on the priority and grouping on the stories. Grouping is done based on the inter-dependencies of the stories<\/p>\n
<\/a>Events<\/h5>\n<\/a>Sprint<\/h5>\nAgile projects are broken down into small, consistent time intervals. These intervals are referred to as sprints.
\nSprints are time-boxed iterations that serve iterative-incremental development.<\/p>\n
\n- All development is done within a sprint<\/li>\n
- A Sprint contains the time-boxed scrum events<\/li>\n
- A Sprint is one month or less, and it is best to have a consistent duration\n
\n- Sprint length is determined by acceptable planning horizon<\/li>\n<\/ol>\n<\/li>\n
- Scrum knows no phases, only Sprints\n
\n- No testing, hardening, release, analysis Sprints<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
The entire point of Scrum Framework is to create a Done increment<\/strong><\/h6>\nA sprint has a time duration of 1 – 3 weeks depending on the extent of the overall project. Before each sprint, there is a sprint planning meeting. This meeting determines what the goals are for that sprint. Based on the team velocity, a set of features are pulled from the top of the backlog. During the sprint, no features are added, and the sprint goals don\u2019t change<\/p>\n
<\/a>Sprint Planning<\/h5>\nThis is the first meeting of every sprint and the amount of work which can be achieved in the sprint is decided in this meeting depending on the team velocity. User stories are assigned to the dedicated team as per the requirement and analysis.<\/p>\n
<\/p>\n
<\/p>\n
<\/a>Daily Scrum<\/h5>\nEvery morning of the sprint the project team gets together for a short (under 15 minute) meeting. This meeting takes place at the same time every day and includes everyone on the project.<\/p>\n
\n- 15-minute time-box daily event.<\/li>\n
- Consistent place and time.<\/li>\n
- Development team inspects their progress toward the Sprint goal<\/li>\n
- Development team creates a plan for the next 24 hours.<\/li>\n
- Not a problem-solving meeting.<\/li>\n
- Not a status meeting.<\/li>\n<\/ol>\n
Each person on the team is tasked to answer 3 simple questions:<\/p>\n
\n- What did you do yesterday?<\/li>\n
- What you are going to do today?<\/li>\n
- Any blockers or dependencies in your way?<\/li>\n<\/ul>\n
<\/a>Sprint Review\/ Retrospective Meeting<\/h5>\nAt the end of every sprint, A Sprint Retrospective meeting takes place with a functional demo of the user stories that has been completed during the sprint. The sprint review meeting brings together the project team and other project stakeholders like the client to present the work that was completed.<\/p>\n
\n- Scrum Team inspects how the last sprint went\n
\n- People, relationships, process, tools<\/li>\n
- Definition of \u201cDone\u201d<\/li>\n<\/ol>\n<\/li>\n
- Scrum team selects actionable improvements for implementation in next Sprint.<\/li>\n<\/ol>\n
<\/a>Scrum events quick reference<\/h5>\n
\n\n\n\nEvent<\/strong><\/p>\n<\/td>\nInspection<\/strong><\/td>\nAdaptation<\/strong><\/td>\nWho Attends<\/strong><\/td>\n\nTime-box for 1 Month<\/strong><\/p>\n<\/td>\n<\/tr>\n\nSprint Planning<\/strong><\/td>\nProduct Backlog<\/td>\n Sprint Goal, Forecast, Sprint Backlog<\/td>\n Scrum Team<\/td>\n 8 hours<\/td>\n<\/tr>\n \nDaily Scrum<\/strong><\/td>\nProgress toward sprint goal<\/td>\n Sprint Backlog<\/td>\n \nDevelopment Team<\/p>\n<\/td>\n
15-minutes (always)<\/td>\n<\/tr>\n \nSprint Review<\/strong><\/td>\nIncrement, Sprint, Product Backlog<\/td>\n Product Backlog<\/td>\n Scrum Team Stakeholders<\/td>\n 4 hours<\/td>\n<\/tr>\n \nSprint Retrospective<\/strong><\/td>\nSprint<\/td>\n Actionable and committed improvements<\/td>\n Scrum Team<\/td>\n \n3 hours<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
- \n
- This is not about the expectation that all scope will be delivered, no matter<\/li>\n
- Commitment is about dedication and applies to actions, the effort, not the final result<\/li>\n
- Maximum possible effort for achieving the goal and will be transparent<\/li>\n
- Commitment towards \u2013\n
- \n
- Quality<\/li>\n
- Collaboration<\/li>\n
- Learning<\/li>\n
- Professionalism<\/li>\n
- Excellence<\/li>\n
- Self-organize<\/li>\n
- Improvement<\/li>\n
- Transparency<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
<\/a>Focus<\/h5>\n
- \n
- Focus on what is most important now<\/li>\n
- Future is highly uncertain, focus on YAGNI \u2013 \u201cYou aren\u2019t gonna need it\u201d<\/li>\n
- Focus on the simplest thing<\/li>\n<\/ol>\n
<\/a>Openness<\/h5>\n
- \n
- Be transparent, inspect in order to make sensible adaptation<\/li>\n
- Open about our work, progress, problems, and learnings<\/li>\n
- Open for people and working with people<\/li>\n
- Acknowledging people to be people, and not resources, robots or replaceable machinery<\/li>\n
- Open to collaborate with stakeholders and wider environment<\/li>\n
- Open in sharing feedback and learn from one another<\/li>\n
- Open for change<\/li>\n<\/ol>\n
<\/a>Respect<\/h5>\n
- \n
- Respect for people, their experience and their personal background<\/li>\n
- Respect different opinions, we might learn from it<\/li>\n
- Respect for our sponsor by not building features that nobody will use<\/li>\n
- Respect for users by fixing their problems and quality product<\/li>\n
- Respect for wider environment by not behaving as an isolated island in the world<\/li>\n
- Respect each other\u2019s skills and expertise<\/li>\n<\/ol>\n
<\/a>Courage<\/h5>\n
- \n
- Courage to not build features that nobody wants<\/li>\n
- Courage in admitting requirements will never be perfect<\/li>\n
- Courage in admitting that no plan can capture reality and complexity<\/li>\n
- Courage to not deliver undone features<\/li>\n
- Courage to share risks and benefits<\/li>\n
- Courage in sharing information that might help team and the organization<\/li>\n
- Courage to change direction<\/li>\n<\/ol>\n
<\/a>Roles, Artifacts, and Events in the Scrum Framework<\/h5>\n
Below diagram depicts various roles and their correlation in the Scrum framework.<\/p>\n
\u00a0
<\/strong><\/p>\n<\/a>Roles<\/h5>\n
Various roles that comprise of scrum framework are:<\/p>\n
<\/a>Scrum Master<\/h6>\n
A Scrum Master is a team leader and facilitator who helps the team members to follow agile practices so that they can meet their commitments. The Scrum Master is responsible for ensuring Scrum is understood and enacted.<\/p>\n
A Scrum Master serves the Scrum Team<\/p>\n
- \n
- Lead by example<\/strong>. Be the first one to be vulnerable. Be a living demonstration of team assets and scrum values. Admit your missteps.<\/li>\n
- Create an environment of safety<\/strong>. Encourage debate, support it and keep it productive. Use coaching techniques like open questions.<\/li>\n
- Facilitate Consensus<\/strong>. Try to have key decisions made clear at the end of team discussions, making responsibility and deadlines clear.<\/li>\n
- Learn to read the room<\/strong>. Be connected without being present.<\/li>\n
- Show patience<\/strong>. Be okay with silence. Let the team take action.<\/li>\n
- Restrain from solving<\/strong>. Reveal, not resolve. Be careful not to steer the team towards premature resolution of conflict to protect people. Help team members develop conflict resolution skills.<\/li>\n
- Be comfortable with failure<\/strong>. Team decisions may not lead to the anticipated outcome. This is part of learning and growth.<\/li>\n
- Care for people<\/strong>. Listen to them without judgement. Assume positive intent. Meet them where they are and help them find the next step.<\/li>\n
- Show low tolerance for organizational impediments<\/strong>.<\/li>\n<\/ol>\n
Below diagram depicts the misunderstood stances of a scrum master<\/p>\n
<\/p>\n<\/p>\n
Stances of a scrum master<\/p>\n
<\/p>\n<\/p>\n
Stances of a scrum master are:<\/p>\n
- \n
- Servant Leader<\/li>\n
- Coach<\/li>\n
- Facilitator<\/li>\n
- Teacher<\/li>\n
- Mentor<\/li>\n
- Manager<\/li>\n
- Impediment Remover<\/li>\n
- Change Agent<\/li>\n<\/ol>\n
Scrum Master as a Servant Leader<\/strong><\/h6>\n
- \n
- Setting up Scrum as a servant process, not a commanding process<\/li>\n
- Guiding the Development Team towards self-organization<\/li>\n
- Leading the team through healthy conflict and debate<\/li>\n
- Shielding the team from disturbance and external threats<\/li>\n
- Helping the team make visible, remove and prevent impediment<\/li>\n
- Creating transparency by radiating information via Scrum events and artifacts<\/li>\n<\/ol>\n
Scrum Master as a Coach<\/strong><\/h6>\n
- \n
- Coaching the Individual in \u2013\n
- \n
- Focusing on mindset and behavior<\/li>\n
- Using Scrum well<\/li>\n
- Taking next step in his\/her Agile journey<\/li>\n<\/ol>\n<\/li>\n
- Coaching the Team in \u2013\n
- \n
- Creating a learning culture<\/li>\n
- Changing mindset for continuous improvement<\/li>\n
- Problem solving and conflict resolution<\/li>\n<\/ol>\n<\/li>\n
- Coaching the organization in \u2013\n
- \n
- Collaborating with the Scrum team<\/li>\n
- Doing product management with a focus on business value<\/li>\n
- Delivering high quality and valuable products<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Facilitator<\/strong><\/h6>\n
- \n
- Facilitate the Scrum framework process and the continuous improvement of the process<\/li>\n
- Facilitate the integration of Scrum team into the wider organization<\/li>\n
- Facilitates the Scrum events to be purposeful and effective\n
- \n
- Daily Scrum \u2013 an atmosphere where healthy peer pressure occurs on delivering quality, commitment and addressing impediments<\/li>\n
- Sprint Planning \u2013 collaboration between the Development Team and the Product Owner, keeping a strong focus on delivering value<\/li>\n
- Sprint Review \u2013 Scrum team, sponsors and stakeholders collaborate to work as One team with the same purpose<\/li>\n
- Sprint Retrospective \u2013 a safe atmosphere in which \u201celephant in the room\u201d is addressed<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Teacher<\/strong><\/h6>\n
- \n
- Teach Agile during the team start-up<\/li>\n
- Teach the Scrum team about Empiricism<\/li>\n
- Teach about Scrum to Scrum team and other stakeholders<\/li>\n
- Teach the difference between Scrum the Best practices<\/li>\n
- Teach the team about the self-organization<\/li>\n
- Team the team about removing impediments<\/li>\n
- Teach the team about the importance of the product vision<\/li>\n
- Team the team about visualizing progress<\/li>\n
- Teach the Product Owner about Backlog Management<\/li>\n
- Teach the team to have fun<\/li>\n<\/ol>\n
Scrum Master as a Mentor<\/strong><\/h6>\n
- \n
- Shu \u2013 Follow the Rules\n
- \n
- Scrum Master acts as a teacher<\/li>\n
- Shares knowledge and skills<\/li>\n
- Provide instructions on \u201cHow to do\u201d<\/li>\n<\/ol>\n<\/li>\n
- Ha \u2013 Break the Rules\n
- \n
- Offers new perspectives and possibilities<\/li>\n<\/ol>\n<\/li>\n
- Ri \u2013 Be the Rule\n
- \n
- Act as a counsellor<\/li>\n
- Give advice whenever asked for it<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
Scrum Master as a Manager<\/strong><\/h6>\n
- \n
- Manages impediments<\/li>\n
- Manages the process<\/li>\n
- Manages the boundaries of self-organization<\/li>\n
- Manages the team\u2019s health<\/li>\n
- Manages the culture<\/li>\n<\/ol>\n
Scrum Master as a Impediment Remover<\/strong><\/h6>\n
- \n
- Respect the self-organizing capability of the development team<\/li>\n
- Creating environment where Development Team feel safe to raise impediments<\/li>\n
- Understand the meaning of \u201cImpediment\u201d<\/li>\n
- Don\u2019t wait until the Daily Scrum<\/li>\n
- Improve transparency by using the Impediment board<\/li>\n
- Be bold and creative in removing impediments<\/li>\n<\/ol>\n
Scrum Master as a Change Agent<\/strong><\/h6>\n
- \n
- Creating an environment that allows the spirit of Scrum to thrive<\/li>\n
- Leading and coaching the organization in its Scrum framework adoption<\/li>\n
- Helping employees and stakeholders understand and enact Scrum development<\/li>\n
- Causing change that increases the productivity of Scrum Team<\/li>\n
- Working with other Scrum Masters to increase the effectiveness of Scrum in the organization<\/li>\n
- Planning Scrum implementation within the organization<\/li>\n<\/ol>\n
Scrum Master Service to the Product Owner<\/strong><\/h6>\n
- \n
- Finding techniques for effective Product Backlog management.<\/li>\n
- Helping the Scrum Team understand the need for clear and concise Product Backlog items.<\/li>\n
- Understanding product planning in an empirical environment.<\/li>\n
- Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value.<\/li>\n
- Understanding and practicing agility.<\/li>\n
- Facilitating Scrum events as requested or needed.<\/li>\n<\/ol>\n
Scrum Master Service to the Development Team<\/strong><\/h6>\n
- \n
- Coaching the Development Team in self-organization and cross-functionality.<\/li>\n
- Helping the Development Team to create high-value products.<\/li>\n
- Removing impediments to the Development Team\u2019s progress.<\/li>\n
- Facilitating Scrum events as requested or needed.<\/li>\n
- Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.<\/li>\n<\/ol>\n
Scrum Master Service to the Organization <\/strong><\/h6>\n
- \n
- Leading and coaching the organization in its Scrum adoption.<\/li>\n
- Planning Scrum implementations within the organization.<\/li>\n
- Helping employees and stakeholders understand and enact Scrum and empirical product development.<\/li>\n
- Causing change that increases the productivity of the Scrum Team.<\/li>\n
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum framework in the organization.<\/li>\n<\/ol>\n
<\/a>Scrum Team<\/h5>\n
It is the team which works for SDLC of the application. This team includes developers, testers, technical lead, product owner and scrum master. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of \u201cDone\u201d product at the end of each Sprint. Only members of the Development Team create the Increment.<\/p>\n
- \n
- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;<\/li>\n
- Development Teams are cross-functional, with the skills as a team necessary to create a product Increment;<\/li>\n
- Scrum framework recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;<\/li>\n
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing or business analysis; there are no exceptions to this rule.<\/li>\n
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.<\/li>\n<\/ol>\n
<\/a>Product Owner<\/h5>\n
A Product Owner drives the product from business perspective and is the one who decides and defines requirements, prioritize their values and release dates. Product owner is also involved in iteration planning and release planning meetings.<\/p>\n
- \n
- Clearly expressing Product Backlog items;<\/li>\n
- Ordering the items in the Product Backlog to best achieve goals and missions;<\/li>\n
- Optimizing the value of the work the Development Team performs;<\/li>\n
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;<\/li>\n<\/ol>\n
<\/a>Artefacts<\/h5>\n
<\/a>Sprint Backlog<\/h5>\n
- \n
- Sprint backlog consists of the selected product backlog items and a plan to deliver them.<\/li>\n
- Selected Product Backlog items are often decomposed.<\/li>\n
- Work for the Sprint emerges.<\/li>\n
- Development team members sign up for work, they aren\u2019t assigned.<\/li>\n
- Development team members may modify the Sprint Backlog anytime, as they see fit.<\/li>\n<\/ol>\n
<\/a>Product Backlog<\/h5>\n
The product backlog is a list of all the product features generally defined by \u201cuser stories\u201d. User stories define everything potential users want to do on the site. There are many tools to keep track of your project backlog, both analogue and digital options.
\nAfter all user stories are created, they are ranked based on the priority and grouping on the stories. Grouping is done based on the inter-dependencies of the stories<\/p>\n<\/a>Events<\/h5>\n
<\/a>Sprint<\/h5>\n
Agile projects are broken down into small, consistent time intervals. These intervals are referred to as sprints.
\nSprints are time-boxed iterations that serve iterative-incremental development.<\/p>\n- \n
- All development is done within a sprint<\/li>\n
- A Sprint contains the time-boxed scrum events<\/li>\n
- A Sprint is one month or less, and it is best to have a consistent duration\n
- \n
- Sprint length is determined by acceptable planning horizon<\/li>\n<\/ol>\n<\/li>\n
- Scrum knows no phases, only Sprints\n
- \n
- No testing, hardening, release, analysis Sprints<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
The entire point of Scrum Framework is to create a Done increment<\/strong><\/h6>\n
A sprint has a time duration of 1 – 3 weeks depending on the extent of the overall project. Before each sprint, there is a sprint planning meeting. This meeting determines what the goals are for that sprint. Based on the team velocity, a set of features are pulled from the top of the backlog. During the sprint, no features are added, and the sprint goals don\u2019t change<\/p>\n
<\/a>Sprint Planning<\/h5>\n
This is the first meeting of every sprint and the amount of work which can be achieved in the sprint is decided in this meeting depending on the team velocity. User stories are assigned to the dedicated team as per the requirement and analysis.<\/p>\n
<\/p>\n<\/p>\n
<\/a>Daily Scrum<\/h5>\n
Every morning of the sprint the project team gets together for a short (under 15 minute) meeting. This meeting takes place at the same time every day and includes everyone on the project.<\/p>\n
- \n
- 15-minute time-box daily event.<\/li>\n
- Consistent place and time.<\/li>\n
- Development team inspects their progress toward the Sprint goal<\/li>\n
- Development team creates a plan for the next 24 hours.<\/li>\n
- Not a problem-solving meeting.<\/li>\n
- Not a status meeting.<\/li>\n<\/ol>\n
Each person on the team is tasked to answer 3 simple questions:<\/p>\n
- \n
- What did you do yesterday?<\/li>\n
- What you are going to do today?<\/li>\n
- Any blockers or dependencies in your way?<\/li>\n<\/ul>\n
<\/a>Sprint Review\/ Retrospective Meeting<\/h5>\n
At the end of every sprint, A Sprint Retrospective meeting takes place with a functional demo of the user stories that has been completed during the sprint. The sprint review meeting brings together the project team and other project stakeholders like the client to present the work that was completed.<\/p>\n
- \n
- Scrum Team inspects how the last sprint went\n
- \n
- People, relationships, process, tools<\/li>\n
- Definition of \u201cDone\u201d<\/li>\n<\/ol>\n<\/li>\n
- Scrum team selects actionable improvements for implementation in next Sprint.<\/li>\n<\/ol>\n
<\/a>Scrum events quick reference<\/h5>\n
\n\n
\n \n Event<\/strong><\/p>\n<\/td>\n
Inspection<\/strong><\/td>\n Adaptation<\/strong><\/td>\n Who Attends<\/strong><\/td>\n \n Time-box for 1 Month<\/strong><\/p>\n<\/td>\n<\/tr>\n
\n Sprint Planning<\/strong><\/td>\n Product Backlog<\/td>\n Sprint Goal, Forecast, Sprint Backlog<\/td>\n Scrum Team<\/td>\n 8 hours<\/td>\n<\/tr>\n \n Daily Scrum<\/strong><\/td>\n Progress toward sprint goal<\/td>\n Sprint Backlog<\/td>\n \n Development Team<\/p>\n<\/td>\n
15-minutes (always)<\/td>\n<\/tr>\n \n Sprint Review<\/strong><\/td>\n Increment, Sprint, Product Backlog<\/td>\n Product Backlog<\/td>\n Scrum Team Stakeholders<\/td>\n 4 hours<\/td>\n<\/tr>\n \n Sprint Retrospective<\/strong><\/td>\n Sprint<\/td>\n Actionable and committed improvements<\/td>\n Scrum Team<\/td>\n \n 3 hours<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
- Scrum Team inspects how the last sprint went\n
- No testing, hardening, release, analysis Sprints<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
- Shu \u2013 Follow the Rules\n
- Coaching the Individual in \u2013\n
- Create an environment of safety<\/strong>. Encourage debate, support it and keep it productive. Use coaching techniques like open questions.<\/li>\n
- Lead by example<\/strong>. Be the first one to be vulnerable. Be a living demonstration of team assets and scrum values. Admit your missteps.<\/li>\n