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 years.
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 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 cleverly named event where the 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…
To prioritize items in a scrum team’s product backlog, the product owner needs an estimate of both value and cost for each item. This way, they can identify which items have high ROI and move them to the top of the backlog. Other concerns such as dependencies must be considered, but in general the team should always be working on the product backlog item (PBI) with the highest ROI.
This makes sense. And yet, most organizations don’t have estimates for the value of the items in their scrum teams’ product backlogs. Why this glaring omission? I believe that it is due to several common myths, or misunderstandings, about the nature of business value.
Read the full article…