A scrum master wears many hats including teacher, mentor, coach, and facilitator. Each is a different stance the scrum master might take when interacting with the scrum team, or others in the organization. Part of the art of being an excellent scrum master is being able to select an appropriate stance for a given situation. We also need to be able to flow between them, inspecting and adapting based on the situation and the needs of the people involved.
This is the act of showing or explaining something to someone so that they acquire new knowledge. The scrum master is an expert in scrum and related agile practices. The scrum master spreads this knowledge throughout the organization, enabling people to engage in their work more effectively. Read the full article…
The big news from the Dublin Scrum Gathering is that Cathy Simpson has become a certified scrum trainer. This is a monumental accomplishment. She is one of less than 250 people in the world, and less than 30 women, who hold this certification. We have had the privilege of working with Cathy over the past 3+ years and supporting her as she climbed this mountain. It’s been inspiring to see her do all of the work required. We couldn’t be more proud of her.
David Marquet was about to become a submarine commander. He spent a year learning everything about the boat he was going to command. Two weeks before he was to assume command he was given a different sub, and the only thing he knew was that it has the reputation for being the worst in the Navy. He made it the best. Here’s how.
Product team is starting to assign business values to epics so we can, along with effort estimates, set correct priorities. However, we also have quarterly goals. Once we reach the end of a quarter, if an epic is not completely done (all stories under it), how do we get partial credit?
I recommend rolling the value down from the epics into the stories themselves. This way, you can see what you delivered in the quarter. Keep in mind that value estimates, just like effort estimates, are really just a tool to help with planning and decision making. At the end of the quarter, I’d like to see you focusing on the awesome stuff you delivered and what your customers’ reactions were to that new functionality.
Here’s an interesting question that just came in from a local scrum master. It’s about estimating tasks and management’s role in choosing the practices that a scrum team uses.
The team I am working with wants to do an experiment where they will stop estimating tasks in hours. Their sprint burn down will then be tasks vs. days instead of hours vs. days. The team believes that they will be successful with this and they are also thinking of creating an initial working agreement for this experiment e.g. any task that will be added will not be longer than a day of effort.
I am supporting this but somehow I have failed in explaining and convincing management. They want me to explain the benefits and the purpose of this experiment. They point to scrum books that say tasks should always be estimated in hours and a burn down chart can only be shown using hours. How do I convince management to allow the team to proceed with this experiment? Read the full article…
How to build shared understanding of the requirements between stakeholders and the development team so the team builds the right thing
How to identify and focus the team’s efforts on the most valuable deliverables
These are topics every member of a high-performing team should be versed in. Having engineers participate in product owner training helps them understand the context within which they do their engineering work, and helps them understand how to interact better with product owners around topics such as the business value of paying down technical dept.
For products that are extremely technical, engineers usually work closely with the product owner in order to define and refine the user stories. If the engineers lack story writing skills, then the resulting ‘stories’ are often little more than a restating of the architecture and technical design. The problem with this is that many of these ‘technical stories’ need to be implemented before there is anything meaningful to the stakeholders. Once those engineers have been exposed to the story writing and splitting techniques in our workshop, they are better able to define/refine stories in such a way that they stay pertinent to stakeholders at all times.
I’ll also point out that all scrum masters should take the product owner training, as scrum masters are the scrum experts who provide guidance to the scrum team and the greater organization. Frequently, the scrum master will be called upon to coach the product owners in the various skills needed to be effective in product owner role.
How long should our sprints be? This is a question I am frequently asked by new scrum masters and scrum teams. Here is how it showed up in my in-box recently.
After we participated in Agile Learning Labs’ Certified Scrum Master (CSM) workshop, my colleagues and I have begun practicing scrum very seriously. We chose one week as our sprint length. Some developers feel one-week sprints are too short, since we have a very strong definition of done. Delivering visible work in one week, along with all of the time in scrum meetings, is too stressful. One team member suggested increasing our sprint length to two-weeks. What are your thoughts?
Thanks for the question! The short answer is keep your sprints short; find and fix the sources of the stress you are feeling. All too frequently, when scrum uncovers a problem, we seek to change the way we are doing scrum in order to cover the problem back up. Have a look at this post about story point accounting for another example of this tendency. A better response is to address the underlying root-causes of the problem.
For your team, it is unlikely the underlying problem is not enough time in a one-week sprint to get user stories done. More likely, the team is dealing with one or more of the following problems: Read the full article…
Here is a question that just showed up in my in-box regarding how to calculate a scrum team’s velocity when they are doing stabilization sprints. This notion of stabilization sprints has become more popular lately, as they are included in SAFe (Scaled Agile Framework).
We do a 2-week stabilization sprint every 4th sprint where we complete regression testing, etc. but don’t take any new stories. Is there a rule of thumb around including a stabilization sprint in the team’s velocity?
The purpose of tracking a scrum team’s velocity is to give stakeholders (and the team) predictability into the rate at which they will complete the planned deliverables (the stories). Velocity is the rate of delivery. The stabilization work doesn’t represent specific deliverables that the stakeholders have asked for; it is simply a cost that you are paying every 4th sprint, because you aren’t really done with the stories during the non-stabilization sprints. Read the full article…