In your description of the Sprint Goal, you focus on WHAT the team needs to accomplish. This approach aligns the goal with the second part (what) of the Connextra template. I prefer to align the Sprint Goal with WHY - using either the “third part” of the user stories or feature benefit hypotheses. In the words of the Guide, “The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.” I find this approach is helpful both in aligning the work of the team with value, as well as with framing the discussion of value that should take place in the Sprint Review and other stakeholder interactions.
Sometimes the impossibility of set a sprint goal shows on other systematic problems - like that one team has too many products, or is altogether wrongly set up, people don't cooperate across their skillsets. I think it is still vital to have the disccussion on what we are trying to achieve in the sprint and then trying to write it down, in case of more goals, at least prioritize them. Or discuss together then what will your team consider as a success by the end of the sprint.
Preach it Mike! Sprint goals turn into mushy abstractions that scrum teams don't have to commit to. If the team puts a lot of time into drafting a sprint goal, these days that means your elaboration to the left of the sprint is weak, the team's DoR is weak, or you're doing SAFe PI Planning :)
Hello Mike, I love watching your videos and find them really helpful. One quick question on sprint goals: An agile coach once told me that it's ok to keep changing sprint goal during the mid of the sprint as Jira allows it. How true is that? Just because allows us to edit the sprint goal can be modified? Or in general is it a good/bad practice to keep changing them. Love to hear your thoughts
That would be a horrible idea. Jira probably lets you delete every item in your backlog. That's a nice feature but it doesn't mean I should do that every week. Set a sprint goal and do your best to meet it.
Hi, I really like the way you're giving the story behind the SG, but what do you recommend instead? I feel like otherwise my team is working "to complete all the tasks in the backlog" and that's not good either!
To be clear, I'm not suggesting that you get rid of a Sprint Goal if you are able to create one each sprint. The main point of a SG is to help the team bring in items that build towards a single objective. A SG also helps to keep conversations throughout the sprint aligned and on-topic. If a SG isn't possible for a team I generally suggest that everyone understands each item in the sprint and that they understand why each item was brought into the sprint. Ultimately, the goal is to ensure that the team is working on the most valuable and high-priority items at any given time, even if those items don't neatly fit under a single sprint goal.
I'm planning to map a sprint goal to a non functional goal of going from a current state to a desired state, as tom gilb encourages with his planguage. This video helped me be pragmatic about my approach. However, I do think that even if the sprint goal might not always be applicable to the entire team, it may still always be useful for every team member to have an idea as to how his own tasks will move the needle of the non - functional business goals of the organization, so as to do meaningful work, staying true to the organization's vision.
I absolutely agree. And I'm glad you're using Planguage. Tom Gilb was, in my view, the original agilist. In fact, I named Mountain Goat Software after one of the principles in his "Principles of Software Engineering Management" book.
Hi Mike, can you give me some advice with regards to stripey teams and the Sprint goal. I appreciate multiple goals are a Scrum anti-pattern but when you have a team made up of backend/frontend and testers as well as being a team delivering several features at once, is it best in this scenario to have more than one Sprint goal to accommodate this otherwise I feel I am setting them up to fail. In theory, a fully functioning team should be cross-functional but in reality, most Devs prefer to stick to their area of strength. If we had one goal per feature each sprint, at least we'd be fully delivering small increments of value. Any advice would be gratefully appreciated. Keep up the fantastic work. 😊😊
Thanks, Helen. I'm not sure I can add much more to what is in the video. I think it is acceptable to forgo a sprint goal when there is no unifying theme or single goal for a team's work. When possible, identify a sprint goal such as, "We will accomplish/achieve/deliver x." If necessary say at most perhaps, "x, y, and z." Each of those could possible cover one or more things (features). I think your mention of devs sticking to their strengths is unrelated to having multiple goals. If not and you have multiple goals because each person wants to work on just one thing and own it, that is a problem I'd suggest addressing.
Hi Mike! Thanks a lot for this video, it's great content! I once heard that Scrum was conceived as a wrapper to XP, what would be your thoughts about it?
Thanks. Scrum predates Extreme Programming (XP) so it definitely was conceived as a wrapper to XP. It can be used that way. In designing XP, Kent Beck looked at the parts of Scrum he liked and added the programming practices that make XP what it is.
I acutally try to make 2-3 goals when they are in that situation - which is most important is by the sequence they are stated in. Is it optimal? No.. but in situations like you mention it acutally work... it just often a slippery slope towards not limiting wip.. which is why we need a coach or a SM to remind them on we are on wrong course.
I think that's the right approach, Svend, when teams have something broader than a single cohesive goal. And great point that at good Scrum Master will prevent a team for abandoning a sprint goal for the wrong reasons. Thanks.
Thanks so much for sharing the video. Quick question. What are the parameters/differentiating factors we need to consider while choosing the form of agile ? For eg. How should we decide if we need to select scrum it kanban?
Thanks. It's on my list to make a video about Scrum vs. Kanban. The quick answer would be that Kanban is the best option for a team whose primary struggle is managing the flow of incoming requests. This is why it's been popular for help desk teams or teams maintaining applications.
In the 1990s, Agile Manifesto was in 2001. An explanation is in order don't you think? I recognize that XP was around in the late 90s. Jeff Sutherland was off experimenting with a precursor to scrum. What were you working on?
I’m not sure what explanation you’re looking for. I started doing Scrum in October 1994. I was a member of the same Usenet forums where Jeff was posting about his early version of Scrum with syncsteps, gaps between sprints, etc. What I was doing was based on the earlier articles by L.B.S. Raccoon, who was influenced by the Takeuchi and Nonaka, and was a CS professor in New Mexico. Dave Olson also had an influential 1992 book called Exploiting Chaos. And Tom Gilb was what I consider the original agilist. His 1989 book, Principles of Software Engineering, outlined the importance of short (one-week) iterations and my company was named in 1991 after one of the principles in his book.
@Mike Cohn I wanted you to explain the history; 2001 was the date the Agile Manifesto was created. People do not know about the 1990s with XP and Pre-Scrum versions. Thanks for explaining. I just saw a post "Agile is 23 years old" on LinkedIn. What you know and what most folks know are quite different. Thanks for the clear history.
That's fine, perhaps I'm doing something better than Scrum then since I don't buy the Scrum Guides claim that Scrum is immutable. If teams don't push boundaries (once they have sufficient experience), Scrum doesn't change. If it hadn't changed in the past, we'd have gaps between sprints, synch-steps, and no retrospectives.
@@MountainGoatSoftware Everything in scrum revolves around the efficiency of working cross functionally. It's usually that teams are not working this way when goals are difficult to define.
@@bartholomewtott3812 That is, indeed, a very common problem. And since Scrum gets its name from the idea of a cross-functional team, you're right that without it a team isn't doing Scrum.
Wow! I love the clarity you have!
Thank you.
The Sprint goals might not totally meet the entire goals of the stories or tasks but it's a focus point for the team
Absolutely!
In your description of the Sprint Goal, you focus on WHAT the team needs to accomplish. This approach aligns the goal with the second part (what) of the Connextra template. I prefer to align the Sprint Goal with WHY - using either the “third part” of the user stories or feature benefit hypotheses. In the words of the Guide, “The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.” I find this approach is helpful both in aligning the work of the team with value, as well as with framing the discussion of value that should take place in the Sprint Review and other stakeholder interactions.
Good approach.
I love the short, topical videos. I also found your books very useful.
Thanks, Jeff. I appreciate it.
Sometimes the impossibility of set a sprint goal shows on other systematic problems - like that one team has too many products, or is altogether wrongly set up, people don't cooperate across their skillsets. I think it is still vital to have the disccussion on what we are trying to achieve in the sprint and then trying to write it down, in case of more goals, at least prioritize them. Or discuss together then what will your team consider as a success by the end of the sprint.
Agreed. All this should be discussed in sprint planning.
Thanks for this video as it provided me insights on how I can coach my team to apply sprint goals in certain situations.
Thanks, James. I'm glad this was helpful.
Preach it Mike! Sprint goals turn into mushy abstractions that scrum teams don't have to commit to. If the team puts a lot of time into drafting a sprint goal, these days that means your elaboration to the left of the sprint is weak, the team's DoR is weak, or you're doing SAFe PI Planning :)
Thanks, James! :)
Hello Mike, I love watching your videos and find them really helpful. One quick question on sprint goals:
An agile coach once told me that it's ok to keep changing sprint goal during the mid of the sprint as Jira allows it. How true is that? Just because allows us to edit the sprint goal can be modified? Or in general is it a good/bad practice to keep changing them. Love to hear your thoughts
That would be a horrible idea. Jira probably lets you delete every item in your backlog. That's a nice feature but it doesn't mean I should do that every week.
Set a sprint goal and do your best to meet it.
Hi, I really like the way you're giving the story behind the SG, but what do you recommend instead? I feel like otherwise my team is working "to complete all the tasks in the backlog" and that's not good either!
To be clear, I'm not suggesting that you get rid of a Sprint Goal if you are able to create one each sprint. The main point of a SG is to help the team bring in items that build towards a single objective. A SG also helps to keep conversations throughout the sprint aligned and on-topic. If a SG isn't possible for a team I generally suggest that everyone understands each item in the sprint and that they understand why each item was brought into the sprint. Ultimately, the goal is to ensure that the team is working on the most valuable and high-priority items at any given time, even if those items don't neatly fit under a single sprint goal.
I'm planning to map a sprint goal to a non functional goal of going from a current state to a desired state, as tom gilb encourages with his planguage. This video helped me be pragmatic about my approach. However, I do think that even if the sprint goal might not always be applicable to the entire team, it may still always be useful for every team member to have an idea as to how his own tasks will move the needle of the non - functional business goals of the organization, so as to do meaningful work, staying true to the organization's vision.
I absolutely agree. And I'm glad you're using Planguage. Tom Gilb was, in my view, the original agilist. In fact, I named Mountain Goat Software after one of the principles in his "Principles of Software Engineering Management" book.
Hi Mike, can you give me some advice with regards to stripey teams and the Sprint goal. I appreciate multiple goals are a Scrum anti-pattern but when you have a team made up of backend/frontend and testers as well as being a team delivering several features at once, is it best in this scenario to have more than one Sprint goal to accommodate this otherwise I feel I am setting them up to fail. In theory, a fully functioning team should be cross-functional but in reality, most Devs prefer to stick to their area of strength. If we had one goal per feature each sprint, at least we'd be fully delivering small increments of value. Any advice would be gratefully appreciated. Keep up the fantastic work. 😊😊
Thanks, Helen. I'm not sure I can add much more to what is in the video. I think it is acceptable to forgo a sprint goal when there is no unifying theme or single goal for a team's work.
When possible, identify a sprint goal such as, "We will accomplish/achieve/deliver x." If necessary say at most perhaps, "x, y, and z." Each of those could possible cover one or more things (features).
I think your mention of devs sticking to their strengths is unrelated to having multiple goals. If not and you have multiple goals because each person wants to work on just one thing and own it, that is a problem I'd suggest addressing.
@@MountainGoatSoftware I absolutely agree - it's a long term goal we're working on moving to a more T-based shaped team. Thanks Mike.
Hi Mike! Thanks a lot for this video, it's great content! I once heard that Scrum was conceived as a wrapper to XP, what would be your thoughts about it?
Thanks. Scrum predates Extreme Programming (XP) so it definitely was conceived as a wrapper to XP. It can be used that way. In designing XP, Kent Beck looked at the parts of Scrum he liked and added the programming practices that make XP what it is.
I acutally try to make 2-3 goals when they are in that situation - which is most important is by the sequence they are stated in.
Is it optimal? No.. but in situations like you mention it acutally work... it just often a slippery slope towards not limiting wip.. which is why we need a coach or a SM to remind them on we are on wrong course.
I think that's the right approach, Svend, when teams have something broader than a single cohesive goal. And great point that at good Scrum Master will prevent a team for abandoning a sprint goal for the wrong reasons. Thanks.
Thanks so much for sharing the video. Quick question. What are the parameters/differentiating factors we need to consider while choosing the form of agile ? For eg. How should we decide if we need to select scrum it kanban?
Thanks. It's on my list to make a video about Scrum vs. Kanban. The quick answer would be that Kanban is the best option for a team whose primary struggle is managing the flow of incoming requests. This is why it's been popular for help desk teams or teams maintaining applications.
In the 1990s, Agile Manifesto was in 2001. An explanation is in order don't you think? I recognize that XP was around in the late 90s. Jeff Sutherland was off experimenting with a precursor to scrum. What were you working on?
I’m not sure what explanation you’re looking for. I started doing Scrum in October 1994. I was a member of the same Usenet forums where Jeff was posting about his early version of Scrum with syncsteps, gaps between sprints, etc. What I was doing was based on the earlier articles by L.B.S. Raccoon, who was influenced by the Takeuchi and Nonaka, and was a CS professor in New Mexico. Dave Olson also had an influential 1992 book called Exploiting Chaos. And Tom Gilb was what I consider the original agilist. His 1989 book, Principles of Software Engineering, outlined the importance of short (one-week) iterations and my company was named in 1991 after one of the principles in his book.
@Mike Cohn I wanted you to explain the history; 2001 was the date the Agile Manifesto was created. People do not know about the 1990s with XP and Pre-Scrum versions. Thanks for explaining. I just saw a post "Agile is 23 years old" on LinkedIn. What you know and what most folks know are quite different. Thanks for the clear history.
@@charlesbrown3rd scrum started in 1993. Agile and scrum are not the same thing, scrum didnt start with the agile manifesto
What if the repeated inability to craft meaningful sprint goal means we need to redo the squads organization?
Daniel, yes, this could be a strong indicator that team's are poorly structured.
Nessy is real. In fact, I know the family. Good people, those.
I'm not surprised she comes from a good family.
If you're not able to define a sprint goal you shouldn't be doing scrum.
That's fine, perhaps I'm doing something better than Scrum then since I don't buy the Scrum Guides claim that Scrum is immutable. If teams don't push boundaries (once they have sufficient experience), Scrum doesn't change. If it hadn't changed in the past, we'd have gaps between sprints, synch-steps, and no retrospectives.
@@MountainGoatSoftware Everything in scrum revolves around the efficiency of working cross functionally. It's usually that teams are not working this way when goals are difficult to define.
@@bartholomewtott3812 Well said. I agree.
@@MountainGoatSoftware nearly all 'scrum' teams I've worked in are not cross functional. It really isn't scrum.
@@bartholomewtott3812 That is, indeed, a very common problem. And since Scrum gets its name from the idea of a cross-functional team, you're right that without it a team isn't doing Scrum.