In this vlog, PST Joshua Partogi shares a simple guideline that he used to help teams improve their Sprint and to get them out of mini-waterfall.

No Scrum team has ever been able to reap the benefits of the framework without making the Sprint Goal a cornerstone of its efforts. The following nine principles point at critical issues any Scrum Team needs to consider on its path to excellence.

Daily Scrum events are filled with 3 questions and meandering discussions about tickets that are in progress. Too many topics and not enough time is the typical opinion. So, how about that Sprint Goal? Likely it’s missing or it’s the token “get all the work done” goal. Stop dividing and conquering. Create a legitimate Sprint Goal and collectively measure progress. When you have a good Sprint Goal, 15 minutes is plenty of time to make a collective plan for the day.

What if the Scrum Team is always only working on a random assortment of work items that seem to be the most pressing at the moment of the Sprint Planning?

What are things that Scrum Teams can actually commit to? What are things that Scrums Teams cannot and should not commit to?

But when you have scrum, for example, you need to deliver an increment every single sprint and that increment needs to be done. So the team needs to have a thing called a Definition of Done and done does not mean met the acceptance criteria. Doesn’t just mean that, there should be other considerations as well. So there’s the definition of done. I don’t want to really call it the checklist for how we do things around here, because that might be a bit too process-oriented and maybe a bit too detailed. There’s a nice balance between trust and being clear what we need to do, but as such the team would know what they need to do for something to be called on at the end of the sprint so they can show something at the end of the sprint. That’s all fine. But what do the developers do in the last week of the sprint? It feels like a loaded question because the assumption that I’m reading from the question is that the developers, in your case, write the code, and then they hand it off to some people who do some testing.

Scrum Guide 2020 mentions Sprint Goal and Product Goal because Scrum teams must have a Share Goal. The Share Goal is always essential, even though the Scrum Guide didn't say it before. Basically, the Common Goal helps the Scrum Team become consciously Autonomous. Because Autonomy will lead to chaos if the group doesn't have a Share Goal. (See picture below) In this article, I would like to share the problems the Scrum Team usually faces when setting their goals and making plans not to be unified or linked to achieving a Common Goal. Thereby, I share with everyone a compact tool that makes it easier for you to define the valuable Share Goals.

In this Scrum Pulse Webinar, Professional Scrum Trainer Mary Iqbal outlines each Scrum Value and provide examples of how these can help your team practice Professional Scrum. In doing so she explores Professional Scrum and how it differs from mechanical Scrum.

What’s the problem with working without purpose? Can you do it? Sure. You can do it, but I mean...

In this energizing 38th Hands-on Agile session, Roman Pichler delved into your questions on the role of the Product Owner. The topics range from product manager vs. Product Owner vs.

In this video, Mark addresses the purpose of Sprint Goals and then explores the message that they are sending when it's hard to define a single Sprint Goal. This can help you ask better questions and steer your team toward higher value.

Does whiskey really help with Sprint Goals? Well, maybe not, but it sure would have helped my nerves creating this simple video about them. The basic idea is that Sprint Goals come first, and they will help the team focus.

Words matter, especially when working in any team setting. Words that are spoken or written by one person can have different meanings when read or heard by another. Scrum Teams have multiple members, which means the interpretation of words used in the team setting increases with each member. The chances of misinterpretation also increases. Shared understanding among members is needed to reduce complexity and provide greater clarity. So the need for a "common language" becomes critical to produce value every Sprint. Create your own playbook to help your teams and organization develop their "common language". In this Scrum Pulse webinar, Professional Scrum Trainer John Riley  demonstrates some theory and components behind a "common language". Words and phrases become less about jargon and more about shared understanding. You will also see some techniques to use in developing a team's common language, and how this language helps a team create artifacts. Some of these artifacts include Product Goals, team agreements, and Product Backlog Items.

Why it matters to have a shared understanding of the product your Scrum team is building.

How does the Daily Scrum support adaptation in order to minimise deviations from agreed goals? Each of the Scrum Events serves to adapt. So does the Daily Scrum. Check out our tips!

There is a lot going on when it comes to delivering complex products in an uncertain and constantly changing world. In this webinar, Scrum.org Professional Scrum Trainer Stephanie Ockerman breaks it down to 5 ways Scrum Teams can discover their opportunities to improve the many different aspects of their process.

In this episode of Ask a Professional Scrum Trainer, John Coleman answers the audience's burning questions about Scrum and the challenges their teams are facing. He answers questions about Product Goals, Sprint Goals, Refinement, Team Dynamics, Performance metrics, Scrum with Kanban and more!

Objectives and Key Results (OKRs) act as goal-setting framework for defining and tracking objectives and their outcomes. OKRs are often misunderstood and are a powerful practice to create razor sharp organisational focus. Isn’t Scrum about goals and focus as well? There is the Vision, the Product Goal, the Sprint Goal as well as the Sprint Review. These elements of Scrum can be very well combined with OKRs. Actually, you might want to turn it around, start with OKRs and map your Scrum implementation to them. In this Scrum Pulse webinar Professional Scrum Trainer Ralph Jocham with Agile Actors #learning  gives a quick intro to OKRs, and you then you will learn how Scrum can benefit from using OKRs to create a network of responsibility from the vision down to individual Sprint Goals. This responsibility network offers a transparency most corporations long for.

Every company has customer focus in its vision or mission statement, but is it really? As an employee of a development team, how do I know if this is the case?

A Scrum team consists of three clear accountabilities: one Scrum Master, one Product Owner, and Developers.  Often, when working with a Scrum team struggling with excessive conflict or a lack of trust, I find the culprit is a lack of clarity around each of these accountabilities.  Even with the best intentions, the Product Owner can become too focused on the upcoming Sprint and not focused enough on the bigger picture.  The Scrum Master can become overly protective of the team, and the Developers - wishing only to please - can take on too much work, jeopardizing the Sprint Goal.     

Scrum is founded on empirical process control, and transparency is one of the three pillars.

Complaining is like releasing gas. It’s a natural occurrence. Everyone does it. But no one wants someone else to do it next to them. How to complain less and do more by Sahin Guvenilir.

In an agile context, we use metrics to set performance goals, measure current conditions, define small improvement experiments and measure the effectiveness of the experiments in order to inspect and adapt goals and determine the next steps.

This vlog with Robert Pieper talks about the importance of Sprint Goals.

In this webinar, Professional Scrum Trainer Ralph Jocham, walks through the different goals in Scrum and shares examples of how they are used and how to avoid challenges when using them.

On today’s episode of YOUR DAILY SCRUM: Who Decides the Sprint Length for A Scrum Team?

This blog aims to shed some light on the underlying forces at play and how good goal setting with well-chosen metrics can help.

In this discussion, Ralph Jocham, Don McGreal, and Patricia Kong discuss how to improve goals by adding specific measures to know when goals are achieved, how to seek toward goals using empiricism, and how to choose measures to help inform improvements. They will talk about Evidence-Based Management, a framework developed by Scrum.org to help organizations use empiricism to set goals and make progress toward those goals. 

Use the do-it-yourself workshops to improve how your Scrum Team uses Product- and Sprint Goals.

On today’s episode of YOUR DAILY SCRUM: What is the Benefit of Having a Sprint Goal?

In the The Evidence-Based Management Guide we talk about the Intermediate Strategic Goal and I likened that to the Product Goal in the 2020 Scrum Guide.

Many organisations wrestle with the seeming incompatibility between agile and release management, and they struggle with release planning and predictable delivery.

In the 2020 Scrum Guide, Ken and Jeff augmented the idea of the Sprint Goal. The Sprint Goal is a commitment to ensure transparency and focus against progress during a Sprint.

In the 2020 Version of the Scrum Guide, the commitments were introduced for each artifact. These then became an element of Scrum; in that they need to be used to gain the maximum value that the Scrum Framework offers. They were always part of a Professional Scrum approach, now there is a clear connection of these commitments to the artifacts. They increase transparency, and the focussed delivery of Value. Each of the commitments now clearly support and sustain an artifact.

This blog post talks about the addition of Commitments to each Artifact in the updated Scrum Guide.

Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum.  The Scrum Guide is maintained independently of any company or vendor and therefore lives on a brand neutral site.  The Scrum Guide is translated and available in over 30 languages.

As per Scrum Guide – The Sprint Goal is an objective that will be met within the sprint by implementing the Product Backlog, and it guides the Development Team on why it is building the Increment.

Help your remote team discover what happens without clear Sprint Goals. And bring back focus together!

Facing a large number of risks while delivering products seems to be normal. And, it is. It is common and natural. What we need to do, is manage the risk.

The focus of this article is on one of the most important things giving lifeblood to the Product Backlog and promoting its characteristic of long-living artifact, the Innovation.

In this post, we describe one tiny experiment that creates transparency about lack of autonomy, and what happens because of it. It won’t create earth-shattering miracles, but I should start the right conversations.

“Can an R&D team of chemists, physicists, electrical engineers, mechanical engineers and embedded software developers optimize teamwork and value by using Scrum? And can live virtual Scrum training deliver a practical Scrum learning experience to everyone on such a functionally diverse team?”

El objetivo de Scrum es maximizar la entrega de valor a través del aprendizaje de los clientes. Scrum se basa en el empirismo y si queremos potenciar sus beneficios se requiere que exista foco en le entrega de valor de negocio. Scrum es una herramienta para lograr la agilidad empresarial. 

Habits first and then progress follows! There is a huge power in the little things.

At many customers I visit, I see a lot of effort being put into classification and managing bugs.

The Scrum Master tactics series are a series of articles in which I write about and explore contemporary techniques that will aid you in your journey as a Scrum Master. The tactics explained stem from my personal experience as a Scrum Master which I accumulated over the years in working with many different teams and contexts.

The fact is, Scrum and DevOps works well together.

Shu-Ha-Ri has been a frequent topic within Agile communities for years to capture the essence, the progress of the journey we embark on as we grow and learn better ways of working.

A physical build monitor - like a light that turns red when a build fails - is a great way to get fast feedback. Its also a fun & educational activity for Development Teams, as it gives them a product of their own they can apply their craft to. And it encourages a Developer Culture.

“Our problem is that we can’t plan Sprints accurately with velocity,” he said. “Some Sprints, our velocity is really high, in others, we barely achieve anything.”