This page is old. Checkout the best list of agile conferences on the web.
I recommend conferences and MeetUps as a great way to learn, network, and earn Scrum Educational Units (SEUs). This past year was challenging for such events. Many were cancelled. Some managed to inspect and adapt, moving online.
I’m pleased to share our 2021 list of agile, and agile adjacent, conferences. It’s the largest list we’ve ever published.
A product owner recently asked if it was okay to want more velocity from their team. Their team usually completed product backlog items (stories) that totaled about 180 points every sprint. The product owner thought: if my team could increase velocity to 200 points every sprint, that would be better.
I think it’s very much a part of the human condition to always want more. However, I’m not sure velocity is what you want more of.
Read the full article…
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 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 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…