How do you calculate the capacity and velocity of a Scrum team?
Velocity is calculated by averaging the number of completed story points in previous sprints. Velocity is used to determine the capacity—how many product backlog items the team should take for the next sprint.
Capacity shows how much availability the team has for the upcoming sprint. Other things held constant, the capacity should be equal to the velocity. However, a few factors can lower the capacity:
- Sick days
- Onboarding of new team members
- Other ad hoc company events or meetings
How could you determine the success of Agile in your company?
There are no universally agreed-upon metrics of indicators to measure that Agile is working. Every company or team should create their own definition of success based on the challenges that they are trying to solve with Agile. Here are some indicators to consider:
- Product increments meet client needs resulting in increasing product metrics—higher retention rates, better conversion rates, increased lifetime value, etc.
- Increased software quality. Fewer bugs, technical debt, etc.
- More effective allocation of resources on high-value products.
- Team velocity is increasing to new plateaus in the beginning.
- Stakeholders more readily participate in agile meetings, especially the sprint demo.
- Team members are happier and refer their friends to open positions in the company.
Why might your team be constantly failing to meet committed deadlines, and its velocity is unstable?
There are many reasons a Scrum Master could investigate:
- People are joining and leaving the team too often.
- There isn’t a good distribution of junior and senior people and the team is imbalanced.
- Definition of ready is not met for user stories and thus the estimates are off.
- The team is working on undocumented legacy code.
- Stakeholders are constantly intervening the process of the team.
- Technical debt and poorly written code.
Should the Scrum team be involved in the product discovery process? Why?
There are a few reasons why the scrum team should be involved in the product discovery process:
- Developers will be able to provide feedback on epics and user stories, which are technically not viable.
- The product owner and scrum team members will develop a common understanding of the market problem and client needs.
- This will foster a sense of ownership amongst the team members, which in turn increases motivation.
Which is the most important Scrum ceremony?
Different ceremonies are important for different reasons, thus one should be careful in comparing them on the same scale. It can create a mindset that one should be prioritized over the other, while the reality is that all of them are very important for an effective Scrum process.
However, taking into account that the goal of the Scrum team is to deliver working product increments, one could say that the sprint demo is the most important Scrum ceremony. During the demo, the real progress of the team becomes known, clients and stakeholders are able to give feedback, the team has to chance to get better acquainted with the product requirements and vision.
Is velocity a good proxy for productivity?
No, velocity is a good proxy for the team’s capacity. While trying to maximize velocity, a team may actually decrease productivity. Team members might minimize re-factoring, skip bug fixing, ignore or spend too little time on unit or acceptance testing, reduce customer collaboration. These practices can offer short-term increases in velocity at the expense of long-term product quality. The goal of a Scrum master is to arrive at an optimal and relatively constant velocity.
The product backlog has over 200 tickets. Is this acceptable?
The product backlog is a prioritized list of all the things that are needed in a product. It is a common practice for product owners to have a separate list of product ideas and as they go into the product backlog they should be prioritized against other items already in it. However, it could be a reasonable compromise to have everything in one place and have only the top half prioritized. A product backlog can have a list of items to be accomplished, but the team will only focus on the high priority items which can add value to the client.
What is a Definition of Ready?
A “definition of ready” provides criteria of what needs to be included in a user story before the scrum team can provide an estimate for it. The product owner or their team are responsible for making sure that all user stories are “ready” before they reach the sprint planning phase.
Your product owner has pushed to include in the upcoming sprint a user story, which does not have the final designs yet. The Design team promises to deliver them on the second day of the sprint. How do you react?
The user story obviously does not meet the definition of ready and could be refused by the team. However, Agile promotes people over process and thus other factors should be evaluated as well. Has the design team consistently met their deadlines in similar situations?
Is there evidence that this user story of very high value to the client? In these circumstances, the team could make an exception and accept the story.
However, it is important for the Scrum master to have a talk with the product owner and make sure that such exceptions do not become the rule. definition of ready is a valuable technique and ignoring it can derail the scrum team’s efficiency and increase the risk of delays.
How would you deal with a team member who considers sprint planning meetings a waste of time and refuses to participate?
The Scrum master should focus on the behavior rather than on the individual. Firstly, you should talk to the team member privately and ask open-ended questions to figure out their reasoning. After that, make a case for the importance of sprint planning meetings and why all team members should participate.
Moreover, you could encourage other team members to voice their concerns during a retrospective regarding the non-participation of the team member in question. Ask them to talk about how that affects the working environment and the team’s performance.
Lastly, if all else fails, you should set up a meeting with the team member’s reporting manager to discuss solutions and if possible consider a transfer to a team that is not using Scrum.
How much capacity would you consider to refactor, fix important bugs, explore new technologies or ideas?
One popular technique is to follow the 15-10-5 rule:
- 15% of a team’s capacity to technical debt.
- 10% to bugs and defects.
- 5% to exploring new ideas.
This distribution ensures enough attention is given to cleaning up code and technical upkeep. Such a setup should be discussed with the product owner and the necessary stakeholders beforehand to avoid misunderstandings.
A product owner assigns user stories to specific team members. How do you react?
The Scrum master relationship with the product owner is very important as it balances the need to deliver product updates as fast as possible and the need to maintain an efficient team. The goal of the Scrum master to explain to the product owner why such actions upset this balance.
By assigning user stories to specific team members, the product owner implicitly claims that they know better than the team who is the best person for the job. This is rarely true as the product owner is not working directly with the team all day and does not have the intimate knowledge of the internal workings of the team. Also, such actions can undercut the motivation of the team as scrum teams are expected to be self-organizing.