I recently had a conversation with Dave, over at the Mastering Business Analysis podcast, about splitting big user stories down into smaller stories. The interview was a lot of fun and it’s available now. You can get it direct from the Mastering Business Analysis website, or point your podcatcher at one of these links:
You can also read about splitting user stories at SmallerStories.com.
Cheers,
This question came from a client: What is the project manager’s role in scrum?
In answer to your question about project managers, there is no project manager role in scrum. The duties of a project manager gets split between the product owner, scrum master, and the development team.
The product owner has the vision of the product and is the business representative accountable for making sure the business is kept up to date about the product, the schedule, and the budget. The product owner does this in multiple ways including:
How should we form scrum teams as our organization adopts scrum?
Deciding how to form teams, and which people should be on which teams is the work of management. Of course there are many ways management might choose to do this. One of the most effective ways I’ve found to figure out roles in a scrum transition is to let people decide for themselves! This may sound shocking (who lets employees or even worse, contractors, decide what role they will fill), but we’ve seen it work very well. The operative word is transformation. The power in scrum comes from its focus on self-organizing teams producing value rather than individuals doing work.
Read the full article…
How long should we time box the prep time before the first sprint starts – i.e. the time used to decide on a product that has a good chance of meeting the goals, make effort and business value estimates and get the top product backlog items to be sprint ready?
I would look for the shortest time you can to prep. To get started in a sprint you need a team and a product backlog. You don’t need a complete and perfect product backlog – since more product backlog items will get added as you go along and existing items will be altered and sometimes removed. I would start working and refining the backlog as you go – so you don’t end up with a “design sprint” that takes longer than a sprint itself.
The 2017 Scrum Guide outlines that up to about 10% of the development team’s capacity will be used in backlog refinement activities. These activities are ongoing and collaborative between the product owner and the development team. The scrum team decides how and when refinement is done. In the initial sprints, that activity might look like several backlog refinement meetings to get the backlog to a state where there are 2-3 weeks of sprint ready product backlog items. After that it may look like one refinement meeting per week and the development team members doing research, prototyping, etc. to get information to refine the product backlog items.
Read the full article…
Our own Cathy Simpson talks about how to do an agile retrospective with your scrum team in this video. The 5-step retrospective agenda she talks about comes from the book Agile Retrospectives: Making Good Teams Great.
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.
Chris,
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…
I was recently asked if engineers or other members of the scrum team would get value from a Certified Scrum Product Owner workshop.
Our Certified Scrum Product Owner workshops are designed to build knowledge and skill in three main areas:
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.
Cheers,
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…
“It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is most adaptable to change.”
— Charles Darwin
Just about everyone agrees that being “adaptable to change” is important.
At the same time, many people believe that we’re entering an age of acceleration. The models underlying society at every level are being redefined as traditional linear models of change give way to the explosive power of exponential growth. According to computer scientist, inventor and futurist Ray Kurzweil:
“The 21st century will be equivalent to 20,000 years of progress at today’s rate of progress; organizations have to be able to redefine themselves at a faster and faster pace.”
At all levels of engineering, we need a management methodology that is “most adaptable to change.”
Is “Agile” the answer? When we ask people to voice their opinions, doubts emerge around the concept of “agile methodologies.” Is it a new buzzword, yet another management fad or a new paradigm for surviving and thriving in times of rapid change? Or is there something better on the horizon?
Join Cathy Simpson of Agile Learning Labs to explore these questions at the next IEEE Technology and Engineering Management Society meeting on April 2, 2015. In this talk, we will look for the “core of agile” that will endure beyond the fad. We will address agile in context. Everything that is old is new again; and perhaps we will discover together that we’ve been agile all along. We just didn’t have the context to know it.
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…