Agile Conference List 2020

Graduates of our workshops often ask how they can continue their journey of learning about scrum, and earn some Scrum Educational Units (SEUs). Attending conferences is a great way to accomplish these goals. Here is a list of conferences that you might consider attending in 2020. I’m sure we’ve missed some good ones, so point those out to us by leaving a comment.

Read the full article…

Share it!

Daily Scrum

Team holding a daily scrumThe 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…

Share it!

Don’t Change Estimates During Sprint Planning

Team estimating user storiesI 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…

Share it!

Role Of Managers In Large-Scale Scrum

Puzzled Manager With LeSS DiagramA 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.

Question

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…

Share it!

Business Value Myths

Pot of gold with rainbowTo 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…

Share it!

Emergency Work In Scrum

Red box with axe in case of emergencyScrum strikes a useful balance between flexibility and focus. In sprint planning, the product owner presents the most important objectives to the development team. The development team commits to as many of those as they believe they can deliver in the sprint. Once sprint planning is over, the business doesn’t change their mind about what they want. The development team is able to focus on delivering the product backlog items to which they committed. At the beginning of the next sprint, the business has another opportunity to change direction in any way they need to.

Every so often something comes up that can’t wait until the next sprint cycle. This could be a problem that has arisen, such as customers not being able to log in. It could be a business emergency such as needing a feature rushed into production in order to land a new client. Such unplanned work is the subject of something that I call “the emergency protocol.” The emergency protocol isn’t an official part of scrum, but it’s a useful addition that many organizations choose to adopt.
Read the full article…

Share it!