Scrum teams are expensive. Salaries and the other costs of maintaining a team represent a significant investment. A well run sprint review can dramatically improve the return your organization gets on this investment (ROI). Sadly, sprint review is widely misunderstood, and poorly implemented. The result is wasted time and lost opportunity. Let’s explore how to unlock the value of sprint review.
Read the full article…
Relative estimation, using story points, has proven itself superior to traditional time-guessing approaches. Common approaches to creating story point estimates, notably planning poker, aren’t great at getting the whole team involved in the conversation. Usually, only the outliers participate. This article describes a better approach, which we have been using with our clients for over a decade.
This approach assumes that your team already has some estimated items in your product backlog. If you don’t, no worries, just use The Team Estimation Game to create your initial estimates. The Team Estimation Game was invented by Steve Bockman, who we were fortunate to work with for several years.
So, you have some product backlog items (stories) with estimates and some new items without. Start by laying out the Fibonacci numbers on a table, or in a shared spreadsheet. When doing this online I usually use Google Sheets, as they allow the whole team to interact with a spreadsheet in real time. Next, take the stories that have estimates and put them in columns (or rows) under the number corresponding to their estimate. Thus, all of the one-point stories will be under the number one. All of the two-point stories will be in a column under the number two, and so on. All of the unestimated stories are in a stack on the side of the table, or in their own column in your spreadsheet.
Read the full article…
I have been assigned as the PO to a non-development scrum team for product marketing. After one week of work, we have delivered only 2 banner ads from a team of 10 people. The problem seems to be the process of approvals, reviews, kickoffs, briefs, tickets etc that need to happen in order to deliver the work. How would you coach me to help everyone see that our current process could be improved?
My first recommendation is to address this in the team’s retrospective. As product owner, it’s appropriate for you to say you would like to see the team get more ads, or other product backlog items, done in a sprint. Be a bit careful though; it’s very easy for the team to hear that as you blaming them or thinking that they’re not working hard. From the tone of your question, I don’t think that’s where you are coming from, but still be aware they may interpret things that way.
In the retrospective, you might consider using the GROW model that I’ve been writing about recently. GROW is designed for coaching, but it’s also great for structuring a retrospective. It stands for: Goal, Reality, Options (and Obstacles), and Way Forward. It’s an arc that you, or the scrum master, might guide the team through.
Read the full article…
Agile coaches often encounter clients that are stuck. They know what they are doing isn’t working, yet they can’t find their way out of the dysfunctional cycle. At least, not alone. The coach’s job is to help their client:
GROW is a framework that a coach uses to guide their client through this process. The client might be an individual, team, or even a whole organization. GROW is an acronym for the stages of the coaching process: goal, reality, obstacles (and options), and the way forward (will do). Let’s walk through the stages of the model, in the context of Scrum.
I spend my working days helping companies effectively use scrum and other agile practices to create healthier working environments and increased business value. Today, I found myself reflecting on the path that led here. Below is an abbreviated timeline of events in the evolution of scrum. I’ve included a few bits of my journey with scrum as well.
1970
Winston Royce publishes “Managing The Development Of Large Software Systems.” This paper is often cited as the origin of waterfall development. While Royce describes what became known as waterfall, he argues against it in the paper. He actually advocates for a more iterative, two pass approach, instead of the single pass of waterfall.
The daily scrum is the event where the development team inspects and adapts their work plan in order to make the most progress possible towards their sprint goal each day. It is one of the most misunderstood events in the scrum framework, and often implemented ineffectively. By understanding the purpose of the event, your team can realize much more value from their daily scrum.
Often, the first thing a person learns about scrum is the traditional way to run a daily scrum. They learn the three magic questions: What tasks did I get done yesterday? What tasks will I do today? What impediments am I aware of?
What people often don’t learn is why the team holds a daily scrum. If team members don’t understand the purpose, it’s very easy for the daily scrum to devolve into a meaningless status meeting, where each team member walks away wondering why they just wasted 15 minutes of their day.
Read the full article…
I encounter scrum teams changing, or worse, creating, story estimates during their sprint planning meeting. This slows down the meeting and it undermines the whole purpose of estimation: predictability.
Predictability is knowing what the business will get and when. Stakeholders might ask the team: “Can we get these features by the end of the year?” Or: “When will the new feature set be ready?”
In a sprint planning meeting, the only predictability needed is a simple yes or no. Is the story (product backlog item) in the sprint? If it’s in, then the stakeholders can expect to get it by the end of the sprint.
The purpose of estimates is to support longer-term predictability, meaning when are we going to get stories from the product backlog? This leads to the reason why we should not change estimates in sprint planning.
Read the full article…
Sprint planning is the very cleverly named event (meeting) where the whole scrum team creates their plan for the sprint. The outputs from sprint planning are: the sprint goal, the forecast of which product backlog items will be delivered, and the team’s work plan.
Read the full article…
A client who is basing their scrum adoption on the LeSS scaling framework recently sent me the following question about the role of manager in Large-Scale Scrum.
I’ve read that when scaling scrum with LeSS, cross-functional teams need to have one manager. The author advocated strongly for this, but in reality, I’ve seen this fail miserably. Losing the domain owner causes the group to skew heavily to the bias of the team manager, as well as lose the ability to strongly drive and foster domain expertise. I’ve seen product people be appointed, and the tech goes to pot. Also, I’ve seen technical people not want to report up through product. I’ve seen engineers as team managers, but it’s rare to find good engineering/product people, and you have the reverse problem. I’m not completely convinced that a team manager is a good idea. Chris, what are your thoughts?
Read the full article…
Sprint planning is the first event of each sprint. Doing it well will align the scrum team and set a course for success. Doing it poorly will waste time, energy, and team morale. Here’s how a product owner can prepare for a successful sprint planning meeting.
Read the full article…