Scrum methodologies
What is Scrum ? Is Scrum a methodologies or framework?
Scrum is a lightweight yet incredibly powerful set of values, principles and practices.
Scrum relies on cross-functional teams to deliver products and services in short cycles, enabling:
• Fast feedback
• Continuous improvement
• Rapid adaptation to change
• Accelerated delivery
• Methodologies in the IT world means detailed, stringent, defined principles and mandatory processes and predefined algorithms. Every process or step should be carefully followed in sequence and documented properly.
• Scrum is always misunderstood as a methodology rather it is a set of instructions given mainly for the product which has high uncertainties, complexities and unpredictable.
• It is a process which works best for all the players emerges from the use of scrum and the boundaries are set by Scrum.
• Scrum as a framework describes roles and rules upon principles that help and facilitate people in a low-prescriptive way.
• The Scrum framework leaves different options and tactics to play the game as it replaces the defined algorithmic approach with respect to people and self-organization to deal with unpredictability and uncertainties issues. The Scrum core values give direction to the actions and the behavior of the Scrum team, and the additions they make to the framework.
• One of the agile methodologies is Scrum which implements Agile principles.
Sprint Planning Meeting:
◦ Attendees: Development team, Scrum Master, and Product Owner
◦ When: At the beginning of the sprint.
◦ Duration: "Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter."
◦ Purpose: Product owner comes with the prioritized backlog and then the Scrum Team plans the items they are going to deliver in the Sprint and the way they will deliver them, estimate them, break into tasks.
From my experiences, the actual duration of the Sprint Planning depends on the team, how well refined the backlog items are, and how good the Product Owner and Development Team is with ordering the product backlog. If you are investing enough time in refinement and what gets refined matches what needs to get done next, I've consistently seen a 2 week Sprint planned in about an hour and a half.
Scrum Values and principles
The principles of transparency, inspection and adaptation are at the hearth of the empirical process control optimizing the value of the Scrum Team's work. The five Scrum values (courage, focus, commitment, respect and openness) enable the transparency, inspect and adapt principles.
Originally, the Scrum guide was based on the three pillars of Scrum. Those three pillars are- Transparency, Inspection, and Adaptation. These pillars were ensuring the team to work collaboratively, adapt to the changes and respect each other’s decisions during work.
Along with the processes of Scrum, there come the core Scrum Values upon which the Scrum framework is based. These are:
Commitment
Committing to something that you don’t understand because you are told to by your boss instead of committing yourself to the team and Sprint Goal.
Focus
Focusing on keeping the customer happy instead of being focused on the Sprint and its goal.
Openness
Telling everyone everything about all your work instead of highlighting when you have challenges and problems that are stopping you from success.
Respect
Thinking you are helping the team by being a hero instead of helping people to learn the things that you are good at and not judging the things that others aren’t good at.
Courage
Even after the decision has been made continuing to push back instead of being transparent, but willing to change even if that means accepting that you are wrong, or that your opinion is not the direction that the team is going.
In your Scrum Team:
1. 1. Put the values on a wall and have each team member write up how they are going to demonstrate the value in their working day.
2.
3. Add a ‘values moment’ to your retrospective. This gives everyone an opportunity to inspect and adapt on their values.
4.
5. Introduce a ‘values’ prize. Not a serious prize, but a fun prize that sometimes can be delivered to two people or the whole team when a value has been demonstrated and everyone is aware of it.
6.
7. The ‘whoops we dropped the value’ prize provides a way of demonstrating courage, but also highlighting when we missed a value. Of course, this prize could end up being a very negative thing so it should always be delivered in a fun way without negative implications.
8.
9. Getting external managers or stakeholders to demonstrate to the team a value and what it means to them.
Agile Values & principles:
Individuals and interactions over processes and tools
Working [products] over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Principles:
1-Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2-Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3-Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4-Business people and developers must work together daily throughout the project.
5-Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6-The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7-Working software is the primary measure of progress.
8-Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9-Continuous attention to technical excellence and good design enhances agility.
10-Simplicity–the art of maximizing the amount of work not done–is essential.
11-The best architectures, requirements, and designs emerge from self-organizing teams.
12-At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Companies that have adopted an agile framework like Scrum report the following benefits:
• Increased ability to manage changing priorities
• Better visibility into projects
• More alignment between business and IT
• Faster time to market1
Empirical Process Control
Transparency
To make decisions, people need visibility into the process and the current state of the product. To ensure everyone understands what they are seeing, participants in an empirical process must share one language.
Scrum Reviews Provide Transparency.
Scrum’s frequent reviews give team members and stakeholders a clear view into the state of the project.
Inspection
To prevent deviation from the desired process or end product, people need to inspect what is being created, and how, at regular intervals. Inspection should occur at the point of work but should not get in the way of that work.
Scrum Reviews & Retrospectives Offer Inspection Opportunities.
Scrum teams inspect their completed work and their process at the end of every iteration during the sprint reviews and sprint retrospectives.
Adaptation
When deviations occur, the process or product should be adjusted as soon as possible.
Scrum Teams Can Adapt the Product at the End of Every Sprint.
Scrum allows for adjustments at the end of every iteration.
Scrum Is Iterative & Incremental
Iterative
A process for arriving at a decision or a desired result by repeating rounds of analysis or a cycle of operations. The objective is to bring the desired decision or result closer to discovery with each repetition (iteration).1
Scrum’s use of a repeating cycle of iterations is iterative.
Incremental
A series of small improvements to an existing product or product line that usually helps maintain or improve its competitive position over time. Incremental innovation is regularly used within the high technology business by companies that need to continue to improve their products to include new features increasingly desired by consumers.1
Product Owner Role & Responsibilities
The Product Owner defines the what--as in what the product will look like and what features it should contain. The Product Owner is expected to incorporate stakeholder feedback to create the highest value product increments each and every sprint. Product Owners maintain the product backlog and ensures that everyone knows the priorities.
Product Owners perform the following activities:
• Clearly express product backlog items;
• Order the items in the product backlog to best achieve goals and missions;
• Optimize the value of the work the development team performs;
• Ensure that the product backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;
• Ensure the development team understands items in the Product Backlog to the level needed.
• Focus on long term and short term goals
• Maximize ROI
• Handle situations with effectiveness
• Take effective and efficient decisions
PRODUCT OWNER ATTRIBUTES
• Empowered. Has decision-making authority for the product.
• Business-savvy. Knows the business, the customer and the market.
• Persuasive. Able to work well with the team and the stakeholders.
• Knowledgeable. Knows the market and the product. Grasps production challenges.
• Available: Is readily accessible to the team and to the stakeholders.
PRODUCT OWNER FUNCTIONS
• Customer Voice: Represents the customers wants and needs.
• Communicator: Knows how to tailor a message to a wide variety of stakeholders
• Decider. Sifts through competing priorities to choose the right product features and says no to the rest.
Development Team Characteristics
Development teams have the following characteristics:
• They are self-organizing. No one (not even the ScrumMaster) tells the development team how to turn Product Backlog into Increments of potentially releasable functionality;
• Development teams are cross-functional, with all the skills as a team necessary to create a product Increment;
• Scrum recognizes no titles for development team members, regardless of the work being performed by the person;
• Scrum recognizes no sub-teams in the development team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
• Individual development team members may have specialized skills and areas of focus, but accountability belongs to the development team as a whole.
ScrumMaster Role & Responsibilities
The ScrumMaster helps the Scrum Team perform at their highest level. They also protect the team from both internal and external distractions. ScrumMasters hold the Scrum Team accountable to their working agreements, Scrum values, and to the Scrum framework itself.
SCRUMMASTER ATTRIBUTES
• Humble. Credits the team, not themselves.
• Respectful. Treat others as whole, creative, and purposeful beings with positive intent.
• Empathetic. Listens to understand. Is comfortable with silence.
• Persuasive. Works to remove impediments throughout the organization.
• Connected. Knows who to talk to (or finds out) to solve problems and resolve issues.
SCRUMMASTER FUNCTIONS
• Coach: Facilitates meetings, conversations, and improvements.
• Protector: Runs interference so the team can remain focused.
• Servant Leader. Leads without authority and puts the team first.
• Agile Advocate: Reinforces agile principles throughout the organization.
Ways ScrumMasters Serve Product Owners
The ScrumMaster serves the Product Owner by:
• Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;
• Finding techniques for effective product backlog management;
• Helping the Scrum Team understand the need for clear and concise product backlog items;
• Understanding product planning in an empirical environment;
• Ensuring the product owner knows how to arrange the product backlog to maximize value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.
Ways ScrumMasters Serves the Development Team
The ScrumMaster serves the Development Team in several ways, including:
• Coaching the development team in self-organization and cross-functionality;
• Helping the development team to create high-value products;
• Removing impediments to the development team’s progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the development team in organizational environments in which Scrum is not yet fully adopted and understood.
Ways ScrumMasters Serve the Organization
The ScrumMaster serves the organization by:
• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product development;
• Causing change that increases productivity; and,
• Working with other ScrumMasters to increase the effectiveness of the application of Scrum in the organization.
Scrum Artifacts
Scrum defines three artifacts: Product Backlog, Sprint Backlog, and a potentially releasable product increment.
Product Backlog
The Product Backlog is an ordered list of everything that is known to be needed in a product. It is constantly evolving and is never complete.
Sprint Backlog
The Sprint Backlog is a list of everything that the team commits to achieve in a given Sprint. Once created, no one can add to the Sprint Backlog except the Development Team.
If the Development Team needs to drop an item from the Sprint Backlog, they must negotiate it with the Product Owner. During this negotiation, the ScrumMaster should work with the Development Team and Product Owner to try to find ways to create some smaller increment of an item rather than drop it altogether.
Potentially Releasable Product Increment
At the end of every Sprint, the team must complete a product increment that is potentially releasable, meaning that meets their agreed-upon definition of done. (An example might be fully tested and fully approved.)
What Is a Sprint Burndown Chart?
A sprint burndown (or burnup) chart is not an official Scrum artifact but many teams use it to communicate and track progress toward the sprint goal during the sprint.
Sprint burndown charts helps teams gauge whether they will complete the work of a sprint. Burndown charts also reinforce the Scrum values of commitment, focus and openness and one of the three pillars of empirical process control: transparency.
Sprint burndowns are a graphical way of showing how much work is remaining in the sprint, typically in terms of task hours. It is typically updated at the daily scrum. As the sprint progresses, the amount of work remaining should steadily decrease and should trend toward being complete on the last day of the sprint. Burndowns that show increasing work or few completed tasks are signals to the ScrumMaster and the team that the sprint is not going well.
Scrum Events
Scrum defines four events (sometimes called ceremonies) that occur inside each Sprint: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
Sprint Planning
What Happens in Sprint Planning?
During Sprint Planning, the entire Scrum Team collaborates and discusses the desired high-priority work for the Sprint and defines the Sprint Goal. The ScrumMaster’s role is primarily to facilitate the meeting. The Product Owner describes the objective of the Sprint and also answers questions from the Development Team about execution and acceptance criteria / criteria of satisfaction. The development team has the final say in how much of the high-priority work it can accomplish during the Sprint.
Who attends Sprint Planning?
Sprint planning involves the entire Scrum Team: the development team, product owner, and ScrumMaster.
How long should Sprint Planning Last?
Sprint planning is limited to a maximum of eight hours.
The general rule of thumb is to allow two hours of sprint planning for every one week of sprint length. That means teams should timebox sprint planning to four hours for a two-week sprint and eight hours for a one-month sprint.
Daily Scrum
What Happens in a Daily Scrum?
The Development Team meets for 15 minutes (or less) every day of the Sprint to inspect progress toward the Sprint Goal. They describe for each other how their own work is going, ask for help when needed, and consider whether they are still on track to meet the Sprint Goal. This is not a status meeting but is instead an opportunity for the Development Team to inspect and adapt the product and process on a daily basis.
Who Attends the Daily Scrum?
The mandatory participants at the Daily Scrum are the development team and the ScrumMaster. The product owner is invited but doesn’t have to attend.
Sprint Review
What Happens in a Sprint Review?
Sprint reviews focus on the product being development, specifically on the potentially shippable product increment created during the sprint. During a sprint review, the Scrum Team invites stakeholders to discuss what was completed during the Sprint. They adapt the Product Backlog as needed based on this feedback. The Product Owner has the option to release any of the completed functionality.
Though a demo might be part of this meeting, the primary purpose of the Sprint Review is the inspect and adapt capability provided by the discussion.
Who Attends a Sprint Review?
The entire Scrum Team attends the sprint review. Any stakeholders, senior managers, and other affected departments (e.g., marketing, customer support) are invited to attend and give feedback. Scrum teams should invite as many people as the room can hold--diverse feedback is essential for creating excellent products.
How Long Should Sprint Reviews Last?
Sprint reviews are limited to a maximum of four hours.
The general rule of thumb is to allow one hours for sprint review per every one week of sprint length. That means teams should timebox sprint review to two hours for a two-week sprint and four hours for a one-month sprint.
Sprint Retrospective
What Happens in a Sprint Retrospective?
Sprint retrospectives focus on the process. During a sprint retrospective the Scrum Team discusses what went right and areas for improvement in the Sprint. They make tangible plans for how to improve their own process, tools and relationships.
What Is the Difference between Sprint Reviews & Sprint Retrospectives?
Sprint reviews focus on the product. Sprint Retrospectives focus on the process.
Who Should Attend a Sprint Retrospective?
Sprint retrospectives are for the Scrum Team, which would include the development team, ScrumMaster, and product owner. In practice, product owners are recommended but not mandatory attendees.
How Long Should Sprint Retrospectives Last?
Sprint retrospectives are limited to a maximum of three hours.
The general guidance is to allow 45 minutes for each week of sprint length. So a two-week sprint would cap the sprint retrospective at an hour and a half; a four-week sprint at three hours.
• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
Definition of Ready: A sprint is a time-boxed development cycle in which items need to be pulled from the prioritized backlog. However, it is very important that the items (User Story) should be in “Ready state”. Pulling unfinished or unrefined user story will make the current sprint delay its deliverables as well as developer will also not be able to develop the expected functionality.
Definition of Done: It represents the acceptance criteria for the Sprint. This list is prepared in discussion/agreement with the Product Owner and Development team on what needs to be completed for user story—it is often standardized across the company in order to deliver consistent product quality.
Sample of Definition of Done is shown below. As per project needs, this can be tweaked.
• Test conditions are written where beneficial to a story
• Unit tests written (where crucial ) and passing
• Acceptance tests written, executed, and passing
• Functional testing complete
• System testing and bug fixing for functionality implemented
• Test cases are written and passing with expected results
• Regression tested where appropriate
• Code complete
• Code committed
Why automation is recommended in Agile?
There have been continuous advancements in software development technologies. When talking about software development methods one can simply not ignore the role that testing plays in software development. Therefore, in order to maintain pace with the latest software development technologies testing needs to be done faster than development.
Imagine you are building a big Software-as-a-Service product like Salesforce. The product has 1,000 features, and you also have to release a new feature every other month to keep up with the competition. Now imagine that you have to test that product, check if new features have not affected old features and every feature is working fine. All 1000 of them. Now imagine that you have to test the whole software within a week.
Not possible, right? That’s what enterprise developers thought before automating the process of testing.
Sprint is generally for 2-3 weeks. In that case, to test the whole software is not easy so recommended way is to automation which drastically reduces the time of testing and every sprint delivers the best quality software.
Pair programming
Pair programming the term derived from Extreme Programming. Pair programming is a style of programming in which two programmers work side-by-side at one computer, sharing one screen, keyboard and mouse, continuously collaborating on the same design, algorithm, code or test.
One programmer, termed as the driver, has control of the keyboard/mouse and actively implements the code or writes a test. The other programmer, termed as the navigator, continuously observes the work of the driver to identify defects and also thinks strategically about the direction of the work.
When necessary, the two programmers brainstorm on any challenging problem. The two programmers periodically switch roles and work together as equals to develop software.
Pair programming is much more effective as compared to code reviews. For code review, the code needs to be completed, but in programming in pairs leads to correct the code instantly without any waiting period. Pair programming is much more efficient as in code review it could be possible that the programmer might not be around. Fewer chances of bugs being corrected.
Benefits of Pair programming
• Fewer defects
• Better decisions
• Higher productivity
• Developers confidence
• Knowledge sharing
• Learning
• Team building
Challenge – The biggest challenge you may face as a Scrum Master is to tackle with the expedited requests for change. An expedited change request from business often leads to disruption of the sprint cycles.
Tip – While the Scrum framework discourages taking any change request during the sprint, however, in practice, it is sometimes not always possible to defer. The way to handle it is to minimize the impact by re-prioritizing the items in the existing or upcoming sprint and ensuring proper communication with the stakeholders to ensure clear understanding of the impact of the change request.
Challenge – Scrum is one of the most agile and robust framework which has changed the way projects are delivered. With quick response time and regular iterations, it helps in overcoming any issues/changes early in the project. That said, one of the major challenges which a Scrum Master faces is to manage conflicts. Conflicts can arise from your team, stakeholders or Product Owner. As a Scrum Master, it is your responsibility to curb them at an early stage and focus on delivery.
Tip – To overcome this challenge, a Scrum Master should always try to be connected with the team and keep them motivated at all time. This comes from having regular discussions with team, asking open-ended questions, having empathy, finding common ground and inspiring your team members to do the same with other team members. This gives them a sense of respect and helps in imbibing the feeling of ownership, thereby contributing to the success of project.
Challenge – ‘Working software’ over ‘comprehensive documentation’, one of the guiding principles of Agile software development is often misinterpreted by delivery teams. Scrum Master needs to ensure that the project delivery teams understand the priority and act accordingly. Documentation is imperative for any project as long as it provides the value and doesn’t obstruct the incremental shippable functionality of the product.
Tip – In order to reduce time-to-market and deliver value to the business, teams need to focus on writing test cases for the system. This is executable documentation that justifies the realities of the working software. Unit test, functional test, acceptance test and integration test not only empower teams to create working software but also create worthy documentation of the system. High ROI(return on investment) and low TCO(total cost of ownership) are the results of a successful delivery team that is engaged, and has the clarity and buy in to guiding principles.
Challenge – I believe the biggest challenge for a scrum master is having the team work collaboratively so we can deliver incremental value to all the stakeholders.
Tips – The way I approach is by the following methods:
Be their coach and mentor.
By adapting the best practices that work best for your team.
By motivating them and making sure that you find innovative ways to conduct scrum ceremonies. The end goal is to remove any impediments and build trust within the team.
Tips –
Change developers/ team mindset from a traditional way to agile methodologies. Coach them regularly via various games/ medium such as ‘Agile Lunch & Learn’, vote for the week (key topics), Retro, etc. Empower the team to be a cross functional team, to take initiatives and to have a feeling of ownership.
Finish Daily Scrum/ Standup in 15 minutes. Arrange a separate discussion session to discuss the roadblocks/ requirements in detail right after the daily standup, if needed.
Finish all user stories within a sprint. Avoid stories being carried forward to other sprints. This can be accomplished by conducting proper capacity planning before embarking on a new Sprint.
Implement the outcomes of the ‘Retrospective’ session. Communicate the learnings to senior management and work with them to implement it before next sprint starts.
In my experience, the main challenges have been in the environment created for the team. At first, this is a legacy environment, as it has been optimized for traditional development, with product managers, program managers, project managers, huge detailed plans, many fixed dates, component teams to ensure maximal interdependencies, policies designed to keep everyone is “fully loaded”, etc. These all tend to keep the team doing pretty much the same things as they did before, the main difference being that they now have a backlog and sprints. All too often, the Scrum team is also assigned a manager, which negates Scrum’s splitting that role into Product Owner and Scrum Master, and ensures that the team will never self-organize. The final coup de grace of this environmental impediment is when the Scrum Master is seen as a project management role. I have yet to see anyone able to effectively coach a team to high-performance agility when they not only have authority over the team, but are also responsible for results and are expected to drive the team to obtain them. In such environments, Scrum can become a tool for micromanagement, which IMO explains a lot of the recent developer backlash against Scrum.
Some of the main challenges include dealing with internal politics (such as when developing functionality that crosses internal political departmental boundaries). It's also difficult when you have to convince or cajole other high level managers to give Agile methods a chance (often: again).
Further, Agile methods do not play nicely with departmental budgets and traditional contract/delivery (one cheque for one set of features). Agile is periodic by nature, which is incongruous with year-end budgeting, for example.
Finally, sometimes convincing developers to embrace Agile is also difficult where old habits are entrenched. Some programmers aren't comfortable with Agile, because it demands courage, transparency and team work. (Some programmers like to sit in the corner quietly; Agile is not always ideal for those more introvert in nature).
There are others, but those are definitely the stand-outs.
Challenges faced by a Scrum Master
Role of a Scrum Master includes facilitating a conducive work environment for the Scrum Team, guiding and teaching Scrum practices to everyone involved in the project and clearing impediments for the team. Apart from this he /she also ensure that Scrum processes are being followed.
The Scrum Master role is very different from the role played by the Project Manager in a traditional Waterfall model of project management. The Project Manager works as a manager or leader for the project. The Scrum Master only works as a facilitator and he or she is at the same hierarchical level as anyone else in the Scrum Team. Any person from the Scrum Team who learns how to facilitate Scrum projects can become the Scrum Master for a project or for a Sprint.
Now let’s see what are the challenges faced by a Scrum Master. The Scrum Master’s wide and open ended scope of Roles and Responsibilities pose several difficulties. They include handling of any exceptions that may arise. Having a subjective and open ended job description creates uncertainty and is very challenging. Prioritizing what should be done first and what can be done later is difficult.
In many organizations, Scrum is implemented project wise and during this transition phase there would be people in the Senior and Middle Management who firmly believe in the traditional ways of getting things done. Managing these unrealistic expectations of management becomes a challenge for the Scrum Master who also has to fulfil the expectations of the Scrum Team. At times this leaves him / her little time to devote to coaching and guiding the Scrum Team on Scrum principles, processes and aspects.
Time-boxing the Daily Standup Meeting to 15 minutes is an everyday challenge for most Scrum Masters. Daily Standup Meeting is conducted only to get answers to the following three questions from Scrum Team, but, often the meeting goes into discussion of small things in detail.
Being a facilitator, Scrum Master has an added responsibility of managing conflicts in Scrum Team, if any. Conflict management is not easy, especially, when it is between the members of the same Scrum Team.
Resisting expectations that the Scrum Master will be a Project Manager is another important challenge. The Scrum Master’s role is very different than a Project Manager’s. But in some organizations the Scrum Master is expected to do a Project Manager’s job which can lead to project failure. Scrum Teams are required to be Self-organized and not controlled by the Scrum Master. His job is to ensure a conducive work environment and help the team remove impediments.
A nightmare for any Scrum master is a Scrum Team not collocated. It may not always happen that the entire Scrum Team sits in the same office. In such cases, the Scrum Master’s job becomes even more difficult. It’s not easy to build a team culture and ensure uniform practices when some members of the team are elsewhere. It’s not ideal to try solving a team member’s problem via Skype or WebEx. If the time zones are too different, even scheduling meetings can be very challenging.
Challenges
Common Challenges: There are seven challenges that most every team new to Scrum face. These are marked as “common” in the challenge. Our belief is that these challenges should be anticipated and included in initial training.
When you ask a Scrum Master what are the challenges facing her/his team, you often hear things such as, “We don’t do daily Scrums well,” or “I can’t get people to the retrospectives,” or “Product Owners don’t want to spend time with the team.” Notice that these are mostly challenges due to lack of motivation and understanding and is often the result of thinking of Scrum as a forcing framework instead of a supporting framework.
Challenges with quality of sprints
• Challenge: Usually having several incomplete stories at the end of a sprint. (common)
• Challenge: Too many stories get started early. (common)
• Challenge: Testing is not complete by the end of the sprint.
• Challenge: Running sprints as mini-waterfalls (common)
• Related FAQ: Does frequent spillover mean we should extend our sprint to 4 weeks from 2 weeks?
• Related FAQ: How can I get people more interested in doing test-first methods?
Events
• Challenge: Having ineffective daily Scrums.
• Challenge: Estimation with Planning Poker takes too long.
Agile Product Management and writing stories
• Challenge: Not being able to write small stories. (common)
• Challenge: Acceptance criteria is not well known for many stories. (common)
• Challenge: Product Owner Not Available (common) coming soon
• Challenge: No Definition of Ready or Definition of Done (common) coming soon
Organization of people and teams working together
• Challenge: Some people needed on a team in order to make it cross-functional are not available full time.
• Challenge: Teams that work together being on different sprint lengths
Top 10 Challenges faced by the scrum master | Supreme Agile
The Role of the Scrum Master (SM) is very challenging. SM responsibilities include Coaching, Training and facilitating both Agile practices and Spirits. In this article, I will review some of the challenges faced by the Scrum Master during his day-to-day activities.
Challenge 1 – No Authority
The first thing that we need to remember is that the SM is the facilitator of the team. However, with that being said, the SM does not have any authority as we would expect to see for such important role. In fact, the Scrum Master can be any member of the team. He is a person who has a good understanding of the Scrum Framework and is a good facilitator.
Challenge 2 – Time-Boxing
I think that any SM will agree, keeping the Scrum activities under a defined time limit is just one of those annoying tasks that no one likes to do. As the team SM, it is our job to ensure that the specific Scrum activates timing is kept. We need to limit the time slippage to a minimum.
Challenge 3 – Role Definition
There is a Hugh challenge explaining the role of the Scrum Master (incl. scope expectations, activities, and responsibilities). I often see lots of misunderstands that arise. This is because some stakeholders in the process do not really understand what they can expect from this role, its importance within the organization and particularly to the team.
Challenge 4 – Management Expectations
There is always a gap between management expectations (relies on old management habits) and new practices that come from an Agile transition.
This makes the life of the Scrum Master really challenging as he needs to protect the team (Especially in the earlier phases of the implementation), while at the same time allowing senior management to take part in the process.
Challenge 5 – Managing Conflicts
The Scrum Master has the responsibility of managing internal conflicts within the Scrum team and sometimes external conflicts that arise from external stakeholders. It is expected that the SM also have the skill to deal and resolve personal issues that may occur.
Challenge 6 – Building the team
One of the main Objectives of the Scrum Master is to assist his team to become “Self-Organized/sufficient”. This can be the difference between a successful team and a complete failure. So how challenging is this task? Well, extremely, just think about a group of people that sometimes have personal issues with one another. It is the Scrum Master’s responsibility to assist them to become a coherent, dedicated, goal-oriented team.
Challenge 7 – Collaboration
As part of the day-to-day activities, the Scrum Master needs to ensure that there is a productive collaboration among the relevant stakeholders. This is especially important between the team and the product owner. This can become increasingly challenging when the Product Owner (PO) is not responsive to the team questions or when decisions are made by the PO without consulting the team.
Challenge 8 – Leader of change
When it comes to Agile transitions, the Scrum Master is the change agent in the organization and should take the lead role in making the change a reality. This is a massive challenge, especially when the organization is still not ready to embrace the change and to adopt the new practices. Remember: making a small change is hard enough, but changing the way of work, state of mind and culture of an organization is a completely different story.
Challenge 9 – Continues Growth
I think that it is a positive challenge that I love to use as an example in my lectures regarding why the SM role is so challenging. This role possesses the responsibility to always learn new ways to improve the personal skills that will be reflected in more efficient and productive way for the organization. For me, more studies that involve both theoretical and practical practices is the key to grow within this role.
Challenge 10 – Gaining Respect
To be able to be a real servant leader of the team and to be able to lead without authority the Scrum Master has one major challenge and that’s to gain the respect of the teammates. This is the main reason that the best Scrum Masters are the ones chosen by the team and not by the organization.
What are then, the main reasons a Scrum team does not succeed (this is a personal list of common issues I've seen so far)?
1. Customers: The very first alarm in Scrum is (in my opinion) the fact that the team cannot visualize customers, talk to them. This is something the SM and the management must clarify before starting (the user story workshop otherwise cannot even start). In case of doubt ask yourself and the team: "What if our team would stop delivering for a couple of sprints? who would scream?".
2. Team members reluctant to do Scrum. Either the manager re-allocate the members not willing to join the team (my preferred choice) or the SM talk to them giving the vision of the path, team goal and learning possibilities to persuade them to (seriously) try.
3. Quality-In & Quality-Out: with these terms I mean the Definition of Ready and Definition of Done that the team must define with the SM and the PO! without these two "contracts" the team will always have problems to accept a user story into a sprint and to consider a story really done (DoR and DoD respectively).
4. User Stories in bad shape: DoR and DoD are really prerequisites but with clumsy user stories (not in INVEST shape) the team will no go really far! Take your time at the beginning of the project, organize a one, two days, one week workshop for user stories writing asking customers, stakeholders, manager and most important an experienced coach that would help in this process. The ground is essential here!
5. Non-supportive management: without a supportive management better not even trying to start (yes, don't!), but what about if the management pretends to know Scrum? well, this is a tricky one. The top management is usually really committed on all the agile practices, They should set few Scrum champions overall the organizations to help the middle-management and the team with the tough decisions (and to facilitate them). Scrum Champs are not roles! these guys have to get their hands dirty by walking among the teams collecting feedback talking with the managers and remove impediments in the organization. Hint: hire a consultant (or a team of consultants) and possibly hire the best.
6. No XP Practices: Scrum is a framework for agile development processes. It does not include specific engineering practices so better if the team starts right from the beginning by experimenting (if new) with some of them. TDD, pair programming and simple design are good candidates to start with (and yes, real Continuous Integration is a must to have since the day 1 :-)).
7. Product Owner: Main risk here is to build something that the customer didn't ask, not usable or not on time. And the risk is even higher is the PO is part of the development team. The product owner should focus 100% on user stories, prioritizing the product backlog, solid acceptance criteria, customer involvement in the development phase and encouraging the team to interact with the customer or the PO.
8. Scrum Master: "The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules" and "The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team". Plus he/she helps the team to learn and grow, in the most general sense (new practices, with impediments, etc). If the SM doesn't do this, is failing!
5 hurdles that Scrum Master commonly face:
1. Managing Role Expectations
Many organizations, as well as the upper management, confuses the role of the Scrum Master with a Project Manager. However, the most important thing that we all should know is that the Scrum Master is a Scrum facilitator for a team as well as an organization.
However, sometimes management expectations are different, which makes the life of a Scrum Master little harder. We all need to understand that Scrum Master is a facilitator, a guide, a process follower and most importantly, a Servant Leader.
2. Change Resistance
As per Mike Cohn, it is the social aspect of change that can create resistance, all resistance comes from specific individuals. Teams or departments do not resist changing to Scrum, Individuals do.
So, when we talk about Scrum implementations, the Scrum Master is the change agent for the same. It’s a major hurdle faced by a Scrum Master during the implementation. Change Resistance is not a surprise, it’s the most expected reaction whenever a new change is introduced.
3. Keeping everything Time-Boxed
When we talk about implementing Sprints, every event is supposed to be time-boxed in order to get productive results. For example, the Daily Scrum event should not exceed 15 minutes, but in reality, we see team members start discussing their technical difficulties and the meeting goes longer than the allotted time. It’s one of the most common challenges for any Scrum Master.
Well, a funny thing to try to overcome this hurdle is to make the team members stand for 15 minutes. Hide all the chairs! They will eventually get tired and finish up the meeting.
4. Handling Urgent Change Requests
Scrum Masters follow the rule when implementing Scrum which is to never accept changes within the Sprint. We can handle the change requests at the end of the sprint or at the start of the Sprint but not in between. However, in a practical world, we see Product Owners/Customers/Stakeholders coming up with an urgent change requests or bugs.
However, it’s also not good to blindly follow the process without understanding the business and market aspects. It’s always better to communicate, collaborate with all the Stakeholders, replan and then make good decisions.
5. Distributed Teams
It is one of the most common barriers faced by a Scrum Master. When the teams are distributed geographically, there are sometimes delays, network issues, cultural or regional issues, different Time Zones, different working hours, it is always difficult to get everyone connected and collaborate/communicate with everyone.
Thanks to all the technologies, applications out there that help us overcome this hurdle whether it’s communication, video conferencing, there are many tools available.
The 8 most important stances of a Scrum Master
Scrum Master is a…
Servant-Leader: The focus is not on his or her own needs, but rather on the needs of team members and clients. Scrum Masters are focused on achieving results while adhering to company’s values, principles and business objectives. They are always available to the Scrum team and stakeholders in order to ensure a good balance between what the team is able to deliver and their quality of life to make sure value is constantly maximized.
Coach: Scrum Masters shape individual’s mindset and behavior for continuous team improvement, and encourage collaboration within Scrum team. They do this by asking the right questions helping team member take ownership of their decisions which promotes autonomy and productivity.
Facilitator: as the name implies, the Scrum Master tries to make everything easier by leaving scenarios ready and providing the team with clear guidelines on what their responsibilities are with the goal of promoting collaboration. They help people overcome their own difficulties to achieve a goal. In other words, a Scrum Masters leadership is the result of their servitude and not imposed by some sort of hierarchy or rule.
Teacher: the Scrum Master ensures that Scrum and other relevant frameworks are understood and disseminated. They also look at the reality of the team and suggests changes that will help it improve in some way;
Mentor: he transfers agile knowledge and experience to the team. It is part of the Scrum Master’s work, based on his experience, to give advice and suggest improvements.
Process Manager: through the management of impediments, Scrum Masters eliminate waste, collaborating to create a high performance team, that delivers value to stakeholders, without compromising the mental and physical health of the team. They manage the limits of self-organization and managing the culture of the group. The are the ones who seeks and helps to implement processes that positively impact the work of the Development Team.
Impediment Remover: the Scrum Master directly handles everything that hinders the progress of the team, keeping in mind the self-organized capabilities of the Development Team. Impediments can be anything, for example, if a member of the Development Team cannot go out to lunch, brings them some food. The point is that Scrum Masters need to be in tune with the needs of the team to understand what could be hindering productivity.
Change Agent: Scrum Masters provide a cultural change that causes new Scrum teams to manifest. They sometimes need to acknowledge that the client has a low level of agile maturity and that it makes sense to summon other Scrum Masters to organize lectures about Agility.
/////////////////////////////////////////////////////////////////////////////////
Explain some common metrics for Agile.
What is the biggest challenge you faced in your project while handling the Scrum team members?
- stabilizing the velocity,
- team members conflicts,
- sticking to time-boxing etc..
State some of the Agile quality strategies.
- Iteration
- Re-factoring
- Dynamic code analysis
- Short feedback cycles
- Reviews and inspection
- Standards and guidelines
- Milestone reviews
- Working Software should be demonstrated at regular intervals
- Individuals & interaction – self-organization, self-motivating should be encouraged
- Customer collaboration
- Welcoming change at any point in time in the project
What is the role of the Scrum Master?
What are the responsibilities of a Scrum Master?
- Tracking and monitoring
- Understanding requirements properly
- Work to reach the project goal
- Process checking master and quality master
- Protect the team from detachments
- Improving the performance of the team
- Lead the meetings and resolve issues
- Resolution of conflicts and impediments
- Communication and reporting
What are different ceremonies and their importance in Scrum?
- Scrum planning,
- Scrum – Daily stand up,
- Scrum review &
- scrum retrospective ceremonies
State some major principles of Agile testing
- Customer satisfaction
- Face to face communication
- Sustainable development
- Quick respond to changes
- Continuous feedback
- Successive improvement
- Self-organized
- Focus on essence
- Error-free clean node
- Collective work
What are the skills of a good Agile Tester?
- Required to be familiar with the concepts and principles of Agile
- Should have an excellent communication to communicate with the team and the clients
- Ability to set priority for the tasks according to the requirements
- Should be able to understand the requirements properly
- Understanding of the risks involved with a project due to changing requirements
Scrum is an Agile framework, right? Name a few other Agile frameworks.
- Feature Driven Development
- Test Driven Development
- Kanban
When can you say your story is ready to develop/groom enough to deliver?
- It is clear and well-written in a format to identify user type, function, and benefits
- It is self-contained i.e. independent of other user story inherently
- It is small so that can be delivered in a single sprint
- It has a defined acceptance criteria for all the functional requirements and appropriate non-functional requirements
- It should have been estimated by the scrum team
- All the external blocking dependencies should have been resolved before starting the sprint
- The resources/team have all the skills required to deliver the sprint
2. How do you manage if the story is high priority and resources left before last day of sprint completion?
3. As a scrum project manager, what are your responsibilities?
- Performing Sprint planning
- To schedule the daily Scrum meeting
- Management of responsibilities of the Scrum process
- Assisting Scrum teams to follow Scrum practices
- Work to remove barriers to allow the team focus on work
- Providing assistance with the Product Backlog
- Co-ordinating with Product Owner to design Product Backlog items for the upcoming Sprint
- Motivating team not to be distracted by the external factors
- Helping team to improve the dynamics to reach the goal
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
- The team finishes early sprint after sprint because they aren't committing to enough work.
- The team misses their forecast sprint after sprint becase they're committing to too much work.
- The burndown line makes steep drops rather than a more gradual burndown because the work hasn't been broken down into granular pieces.
- The product owner adds or changes the scope mid-sprint.
- Epic or release forecasts aren't updated as the team churns through the work.
- No progress is made over a period of several iterations.
- Chronic scope creep, which may be a sign that the product owner doesn't fully understand the problem that body of work is trying to solve.
- Scope grows faster than the team can absorb it.
- The team isn't shipping incremental releases throughout the development of an epic.
- Are there unforeseen development challenges we didn't account for when estimating this work? How can we better break down work to uncover some of these challenges?
- Is there outside business pressure pushing the team beyond its limits? Is adherance to development best practices suffering as a result?
- As a team, are we overzealous in forecasting for the sprint?
- Increasing cycle time -Increasing cycle time saps the team of it's hard-earned agility. In the team's retrospective take time to understand an increase. One exception: if the team's definition of done has expanded, cycle time will probably expand too.
- Erratic cycle time – The goal is to have consistent cycle time for work items which have similar story point values. Filter the control chart for each story point value to check for consistency. If cycle time is erratic on small and large story point values, spend time in the retrospective examining the misses and improving future estimation.
- Blocking issues create large backups in some parts of the process and starvation in others.
- Unchecked backlog growth over time. This results from product owners not closing issues that are obsolete or simply too low in priority to ever be pulled in.
- How many defects are found...
- during development?
- after release to customers?
- by people outside of the team?
- How many defects are deferred to a future release?
- How many customer support requests are coming in?
- What is the percentage of automated test coverage?
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
SCRUM: 22 cloud
Velocity should only be used for the team for planning purposes. The success of the team should always be based upon the delivery of value--i.e. a working increment of the product delivered to the customer.
https://agiledigest.com/agile-digest-tutorial-2/capacity-planning_n/
What is Capacity Planning
Planning the Capacity means estimate and calculate the capacity of Agile team. There are two widely used capacity measurement units
1. Story Points
This is Simple way to calculate the velocity (Average of last 6 to 10 Sprint’s Accepted Story Points). and target the upcoming Sprint to commit the User Story that closely match with the velocity.
I Personally recommend the other way of doing the capacity planning by calculate it by Hours.
2. Hours
I personally recommend Capacity Planning by Hours. I will explain only on this way of Capacity Planning in this Article. Its gives better visibility and accuracy. And many other benefits that we will discuss later in this article.
Here we Calculate the available bandwidth of the Agile Team (except PO & SM). By calculate their available hours for the upcoming Sprint.
Will discuss in details about who to calculate it, what are Factors we should consider in this article.
How to do Capacity Planning (in Hours)
The technique is very simple to calculate & plan your capacity. I have explained below the steps to calculate it manually. However in todays days all major popular ALM tools have that inbuilt, You just need to feed in the details.
At the end of this article will show example of doing Capacity Planning in one or two ALM tool.
I have explained below step by step you can follow to do your capacity planning, even if you are not using any ALM tool, just by maintaining an Excel.
Step 1 – Calculate Sprint Duration
Calculate the Sprint Duration in Days, Identify the Sprint Start Day and End Day. To explain this I have taken a 2 Week Sprint which Start on Wednesday and Ends on Tues day. And we are doing our Capacity Planning for Sprint 2.
The picture in the right Represent a 2 week Sprint – Calendar, of 10 days. Spread in three Physical Calendar Week. Through out the rest of the article, I will explain with this color legends , where
Yellow = Previous Sprint
Green = Current Sprint (for the Sprint we are doing the Capacity Planning)
Blue = Future Sprint.
Step 2 – Calculate Team Members Availability
Assuming We have 7 Members team 4 Developer and 3 Testers, Not Counting the SM and PO here, as we don’t need to count their capacity in Capacity Planning
Step 3 – Identify Allocation %
Now Identify the Shared resource if any, If there is No shared resource, we will count every one is 100% allocated to this Scrum Team. For example lets assume we have one Tester (Tester 3) who is shared between two teams, and his allocation is 50% for this team in example.
Step 4 – Calculated The Standard Hours per day
If we assume every one has 8 hours per day on full allocation, The Shared resource will have 4 Hours per day allocated for this team. For this sprint.
For 10 Days Sprint the total Max capacity is 520 Hours for the entire Team and having 52 Hours per day, Including Shared Tester. Every One has 80 hours for 10 days and the Shared Resource with 50% allocation have 40 Hours, for this sprint Duration.
Now Lets See how does that looks like in our calendar
Step 5 – Consider The Factors
1. Team Holiday
Mark the date that is off for the entire team. National Holidays etc.
2. Calculate the Individual working off.
Calculate based on – if any resource have planned off / out of office.
3. Override default working day hour.
If Required – Take an exception for individual team member, to change default hours from 8 Hours to some thing else, Specially if some one has a plan half day or the plan hours have other than other than the default 8 Hours (100% Allocation)
Assuming – 9th of Jan is a Team Holiday
In this case : we can see from this picture, that the total and Individual capacity is reduced accordingly.
Assuming – Developer 1, Developer 2 and Tester 1 have a Planned full day off for three different days. By applying that we can see from this picture, that the total and Individual capacity is reduced accordingly.
If Developer 3 plans a Half day work on 13th Jan. The plan capacity will change accordingly as below
Step 6 – Consider Other Work that eat up Times for every one
Consider the Time it will take for other meetings and Agile Ceremonies. The below picture represents typical time a Teams Spends each ceremony and other meetings
Reduce 12.33 Hours from the Capacity
Step 7 – Consider Focus Factor
Plan it accordingly to your team can focus, for any unplanned time loss keeping in mind the daily time off, adhoc unplanned meetings , other official activity, training, Discussion with SME etc. Remember for planned activity your can still calculate before hand. We keep focus factor for any thing that can not be plan. That value can vary 75% to 95%
So The Final Capacity for this Team for Sprint 2 is 318.32 Hours
Summarizing the 7 Steps
Calculate Team members Allocation
Calculate – Standard Working Hours / Day
Calculate Ceremony Time
and other work
Please Note
The Values , Percentage and amount of hours are for the above example only. You need to put values based on your own need and facts.
- Calculate the Focus Factor the best suits your project.
- Sprint Duration as per your Sprint Cycle
- Plan it for Developers/ Tester and any other Role in your Scrum team (except SM and PO)
- Team members allocation as actual in your team
- Factors like Team Holiday, Planned Vacation, partial are not just limited to these tree factors.
- Calculate the Times of Ceremonies as per your schedule with addition to any other planned meeting
- In The above example I have not calculated the vacation day is falling under any ceremony day, to avoid complication and granular level calculation.
When we should do Capacity Planning
With Scrum Master’s facilitation A Scrum Team can identify the capacity before the sprint planning. The best time is just before the Sprint Planning for any specific Sprint, That gives the best visibility of Resource’s vacation plan or Ceremony time.
If the Team is using any ALM tool, Individual team can update their available time, Scrum Master can help the team understand how to calculate their Individual Capacity. Before hitting the Sprint Planning, the Scrum Master can conduct a quick 30 min meeting with the team and get the Capacity Calculated and Update accordingly. When I was a Scrum Master I used to calculate all the factors in Excel initially with the team 1 or 2 day before Sprint Planning, and eventually the team was mature enough to do that by their own with very minimal intervention.
Benefits of Capacity Planning
Capacity Planning helps the team to gauge the available bandwidth for the team to commit and complete User stories. Specially when you estimate your capacity by hours and map task of committed user stories with the Individual capacity and his/her assigned estimated task hours. The team can identify the limit of committing user story in Sprint Planning. We will discuss more in details how we map our tasks and capacity during Sprint Planning, in a different article of Understanding Sprint Planning.
The Reason why I always prefer Capacity Planning and Mapping on Hours Rather than Velocity is, Its easy to calculate available Hours by simply math with Days, Vacation, Leave, Other Time, Focus Factor etc. to get a Team Capacity. That’s is technically not possible with Velocity and the team needs to make assumptions which is dangerous,
Secondly you can not assign a Story (having Story points) to a single member, as completing a story is mostly a team effort. And distributing any story points between team member, Huh!! Cant even think about it, where One Story (what ever the story point is) can have multiple tasks (each task having efforts estimated in Hours) can easily be assigned to one or more Team Member, each task can assigned to each member. We will see more in details with demonstration in a different article of Understanding Sprint Planning.
http://www.agilebuddha.com/agile/how-to-do-effective-capacity-planning-on-the-scrum-team/
What is Capacity Planning
Planning the Capacity means estimate and calculate the capacity of Agile team. There are two widely used capacity measurement units
1. Story Points
This is Simple way to calculate the velocity (Average of last 6 to 10 Sprint’s Accepted Story Points). and target the upcoming Sprint to commit the User Story that closely match with the velocity.
I Personally recommend the other way of doing the capacity planning by calculate it by Hours.
2. Hours
I personally recommend Capacity Planning by Hours. I will explain only on this way of Capacity Planning in this Article. Its gives better visibility and accuracy. And many other benefits that we will discuss later in this article.
Here we Calculate the available bandwidth of the Agile Team (except PO & SM). By calculate their available hours for the upcoming Sprint.
How To Do Effective Capacity Planning on The Scrum Team
During sprint planning, scrum teams often face this challenge of sprint commitments. How many stories can we commit in this sprint? How to plan for the team capacity?
I ask teams to do commitment driven planning during early stages of scrum adoption. For you to commit to a sprint goal, you need to know current team capacity. Team capacity is calculated as per people availability in that sprint.
Let’s take an example.
Say team is of 5 people, then total capacity assuming 8 hour day, 2 weeks sprint(10 days) is = 5*8*10 = 400 hours. Planning for this total capacity will be disaster. It will lead to team working over time, rushing towards the end, quality cuts and low team morale.
Then to what capacity team can commit for? How can team make this sprint planning effective?
I prefer to use Focus Factor (F.F) on this total capacity to arrive at real capacity for sprint commitments/forecasting. This factor lies in the range 0.6 – 0.8.
So what is focus factor then?
Traditionally, project managers used 6-6.5 hours as planned hours in a day for project execution. Focus factor is teams ability to remain focussed on the sprint goals without any other distractions. After multiplying total capacity with focus factor you get real capacity against which you can make sprint commitments or forecasting. This is the effective hours you can expect from the team.
In this example, applying focus factor say 0.6, then this team real capacity will be 400*0.6 = 240 hours.
Now this 240 hours of work is what the team can take up in the current sprint. Teams take top priority stories from the backlog as per ordering done by PO. Divide those stories into tasks as shown below and estimate each task for hours. Team will take on the stories till the time all the tasks sum to not more than 240 hours(in this example).
I use lesser focus factor(say 0.6) on the following situations:
- When team is starting new on a project
- Team is using scrum for the first time
- Team is working on a complex product or new to technology domain
- Team is less matured, needs lot of handholding and so on…
I prefer to start a team on successful note(improves morale). Using lesser focus factor when you start fresh and then if team meets sprint goals early, then they can take up more in the current sprint. Retrospect on this in coming sprints to see if you want to increase focus factor marginally and fine tune, iterate this factor as you go, to reach sustainable pace/Flow. Going beyond 0.8 can be risky and can derail teams too.
If organisation or product development is very chaotic then this factor will remain on extreme left like 0.6 or may be below. Chaotic organisations have lot of unplanned meetings, pre-sales urgency, hiring team coming to the project team at a last minute with a interview request, not having defined core working hours, lesser clarity sprint backlog, wrong team structures(read too much inter-dependency) and list goes on… To summarise – no rhythm.
This factor takes care of all the team distractions(SM effectiveness), time taken by the team to do scrum ceremonies, team meetings facilitation effectiveness, organisational efficiency and more. During the retrospectives, analyse WHY and put action items to fix them.
Tip 1: Please don’t use buffering at task level as FF will take care of it at sprint level. Use ideal time(actual effort if there is no distraction) for task estimation in hours.
Tip 2: One major factor that drags focus factor is people being allocated to multiple projects, overhead of task switching comes to play. Try to minimise this if you can not avoid
Capacity-Based Sprint Planning
There are two ways of Sprint Planning.
- Velocity-based Sprint Planning
- Capacity-based Sprint Planning
Velocity-based planning of the Sprint determines how much work the team can accomplish in the Sprint. In any Sprint, the velocity is calculated as the number of Story points completed per sprint. This is a basic introduction to Velocity-based Sprint planning. We will learn more about this type of sprint planning in the next section .
What is Capacity or Commitment-based Sprint Planning?
Capacity-based sprint planning, also called Commitment-based Sprint planning, is based on the team’s available capacity (in hours) for the sprint and tries to fill that capacity effectively without overburdening and under committing the team members. Capacity-based planning is considered the best way of sprint planning due to the following 3 main reasons.
- The capacity of the teams may vary from one sprint to another, depending on holidays, leaves, or other commitments. So, every sprint is not an average sprint.
- The story points and the velocity are the two important measures over multiple sprints for estimating the release dates. But story points are found to be coarse-grained for planning the details of a two-week sprint. If you consider the hours, they are fine-grained enough and much useful for estimating concrete tasks.
- Lastly, in the Sprint Planning, the user stories allow the development team and the Product Owner to consider each story in detail to develop a shared understanding of the end product.
In capacity-based sprint planning, a team commits to one product backlog item at a time by roughly estimating the involved tasks and finishing the task when they feel that the Sprint is full.
While planning a capacity-based sprint, it is crucial that the team’s commitment is not looked at as a guarantee. Here, commitment can be viewed as a team’s commitment to do its best. In fact, teams can perform at their highest level 80% of the time. The commitment should be something that can be taken seriously and should utilize most of the time. In this way, businesses gain the confidence of in what time they can deliver the products.
Who all participate in the Capacity sprint planning?
A capacity or commitment-driven sprint planning meeting involves the Scrum Master, Product Owner, and all the development team members. The Product Owner presents the highest-priority product backlog items in the meeting and introduces those top-priority items to the team.
How to do Capacity-based sprint planning?
Scrum teams often face the challenges of sprint commitments during a sprint planning. The challenges include-
- How many user stories can the team commit in a sprint?
- How to know the team’s capacity?
The second challenge is a crucial one because for committing to the sprint goal, you need to know the capacity of the current team and the capacity can be calculated as per team members’ availability in the sprint.
Let’s understand it with an example:
Consider a team consisting of 6 people working for 8 hours per day for 3 weeks sprint (15 days). Then the total capacity of the team can be calculated as-
Team’s Capacity = number of team members * time in hours * days
= 6*8*15
= 720 hours
But planning a total capacity in this pattern may-
- Burn out the team with loads of tasks
- Make them rush to reach the end goal
- Hamper the quality and lead to low team morale.
Then how to decide the capacity that the team can commit to? And how the team can make the sprint planning events more effective? Focus Factor (F.F) can be used to get the real capacity.
This focus factor lies in the range of 0.6 - 0.8.
What is Focus Factor?
Project Managers generally plan for 6-6.5 hours per day for executing a project. So, focus factor is nothing but the capability of the teams to stay focussed on the sprint goals without any impediments. You can get the ‘real capacity’ when you multiply total capacity with a focus factor. E.g. Consider, focus factor is 0.6, then the real capacity of the team will be 720 * 0.6 = 432 hours.
What is the Output of Capacity-based Sprint Planning?
Sprint Backlog is the output of the Capacity-based Sprint Planning meeting. A Sprint Backlog is nothing but a list of the product backlog items that the team commits to deliver plus a list of tasks needed to deliver those product backlog items. Also, each task on the Sprint backlog is usually estimated.
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Comments
Post a Comment