A Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog (cit. Scrum Guide). Have you clearly defined a Sprint Goal at the end of your Sprint Planning? Is this Sprint Goal understandable and transparent to everyone? Is it defined in a way that provides guidance and flexibility to the Development Team? The aim of this article is to raise awareness on the importance of having a Sprint Goal defined and to provide some suggestions on how to create one.

A paradox is something that is seemlingly absurd but really true. When I experience complexity and uncertainty, I find comfort and power in paradox. It opens up creativity, possibility, and collaboration. Let's take a look at 4 paradoxes we need to navigate in the agile world and beyond.

Scrum Masters are often understood mostly as “team coaches”. Yet, their role is vastly more important. The Scrum Guide emphasizes that Scrum Masters are responsible for leading and coaching organizations in the adoption of Scrum and causing change that increases the productivity of the Scrum Team.

A couple of years ago I blogged on Innovation Accounting in Scrum, and the bringing of empiricism to Product Ownership. On Tuesday I gave a presentation on this topic to the Agile Northants UK meetup. There was a pretty good Q&A afterwards.

I collected lots of feedback from different students around Europe that attended my Professional Scrum Developer Training. Here some photos to give you an idea...

Many organizations struggle in their implementation of Agile and/or their evolution of agile once they start their journey. They use practices, people, and technology to find a way to overcome their disability of delivering value to market too slowly.

In your organization, some problems seem to recur, they are difficult to fix using the tools, tricks and practices you developed over the years as a manager. Maybe this problem is different and the perspective of an expert-outsider might help?

In this article I will stress again the utmost importance of understanding the context of the organization as a strategy to achieve a possible, evolutionary and deep application of Scrum within organizations.

I always assume that the people I work with are professionals - and not children. This is why I don’t like maturity models in whatever shape or form. And we’ve got a lot of those in our industry.

Ever wonder what a Scrum Master does all day? If you’re new to the role of a Scrum Master, you might think you have to facilitate all the events, take notes and schedule outlook meetings. Turns out you don’t have to do any of that!

Quite a few teams in organizations implementing Scrum depict their frustration in statements like “Scrum is driving us crazy!”, “It’s too chaotic!”

Last week, I had a long discussion with my friends about how to scale up the Scrum Team from the startup product. That was an interesting topic and we had many things to discuss. Some of my friends raised some interesting questions.

Leadership means having the responsibility to enable an environment that harnesses the full intellectual talent of an organization. We hire a bunch of top diverse talent but limit them by unintentionally having them work only within their part or silo of a large organization.

One of the biggest misconceptions of agile is that it focuses on speed. How fast can we deliver? How fast can we deliver on this project/product?

The comparison between Kanban and Scrum obviously comes up often when we're talking to teams, especially in the context of Professional Scrum with Kanban. While they are more similar than many practitioners realize, one key difference is the perspective on Teams. 

Teams are becoming the fundamental organizational entity, individual responsibility is being replaced by that of the team. But responsibility does not come about all by itself.

I was working with various groups over the last year and noticed some commonalities in the problems they faced. In this blog I want to share some common collaboration problems and solutions I experimented with.

From my experience, nothing is more important for Teamwork than trust. If having the secondary importance, it’s TRUST as well. You can't build a good team while they lack of trust.

This is the start of a series of articles about the Scrum.org PSM II class. It will address the most common questions asked. This article is focused on the difference between the PSM and PSM II class.

Flow of work and, most importantly, value is paramount. There are times when you keep looking at the process and don’t understand what is going on, what is wrong, and why stuff is not getting to done. Read to learn how flow can help while limiting work in progress.

The House of Scrum metaphor and sketch seemed to have piqued some interest last year. In this video I go over the 3-5-3 framework, giving a high level overview of Scrum..

Organizations are always on the lookout to cut costs and scale back when they have unfavorable reporting periods. Hiring freezes, and cutbacks in training and traveling tend to be popular and convenient.

People may have talked about these things earlier and I would like to share my experience around it. This story is long dated back when I was working on a software product for a manufacturing domain client.

I read somewhere that multi-tasking makes you stupid. So, I did some research to understand why. What I learned was both interesting and revealing.

A college roommate of mine retired this week, after a long and successful career. While he's figuring out the next chapter of his life, it caused me to think about whether the notion of a "career" is even relevant in today's world.

Many large legacy organizations are moving toward agile delivery methods in hopes of releasing faster to market. Based on my experiences, they look at it solely from a production view of getting software released faster and more often. This view has them believing this will result in getting more features released.

Through my professional experience, while serving my customers, working with Scrum Teams and training people in Professional Scrum, I have observed that some Scrum Masters only work to serve the Development Team and the Product Owner.

Ask any Agile practitioner these days what Agile values are and he/she, most likely, will recite you some lines from the Manifesto for Agile Software Development.

As many Professional Scrum Trainers have experienced, there is always a good discussion around the Sprint Goal. A similar discussion recently led me to address this not so well understood aspect.

One of the most important things we can do to help individuals and teams improve is coach them to embrace the agile mindset. The Manifesto for Agile Software Development provides values and principles to help guide teams in navigating the complexities of product delivery.

Our trainings around Scrum aim at gaining knowledge in applying Scrum to improve on product development. To achieve this in an ideal way, we deliver our training in the language spoken locally.

Building (and hiring) a great team takes time and effort. Patrick Lencioni’s “The Five Dysfunctions of a Team” became a staple reading in an Agile community these days.

A common phrase that I use in my classes is that Scrum is like the poker game Texas Hold’em; it only takes a few minutes to learn but a lifetime to master.  The “few minutes” may be a bit of a stretch but my students get the point. 

What is Scrum Team Velocity? This is a tricky one, and you need to be answering it in the context of the organization you are interviewing with and its complementary practices.

I have been fortunate enough to have a successful career as a change agent. I leverage my experience of navigating the world with Cerebral Palsy — a world that was not yet ready to deal with a person with a disability — to help companies deal with their disability: their inability to change from the status quo.

Have you heard the term “lamp post metric”? [i] This is a measurement that is easy to gather and may even seem like common sense. If you lose something on a dark night, where are you going to look?

In the previous 3 articles on the Agile Metrics topic, I reviewed some of the most important Agile metrics that ActionableAgile software helps you to get with ease. Here we take a look at the ways the software can help you in forecasting your work.

In the first part of Getting to 85 – Agile Metrics with ActionableAgile we looked at the Cycle Time Scatterplot created by ActionableAgile software. The second part was all about the CFD. Now it's time to look at the Aging Work in Progress chart.

This question "What is the duration of a Sprint" is seemingly simple, but depending on the interviewing situation, company, interviewer, and their familiarity with Scrum you might need to give them more or less details and answer additional questions your answer might bring up.

In today’s complex ever-changing work, we need to make full use of the collective intelligence of the whole team, even if the whole organization to be able to solve and deliver on these needs.

In the first part of Getting to 85 – Agile Metrics with ActionableAgile we looked at the Cycle Time Scatterplot as generated by ActionableAgile software. That piece also discussed some ideas the scatter plot could bring about and conversations that potentially might occur.

Scrum and Kanban are a great combination. With this insight more and more Scrum Teams become aware of terms and phrases used in Kanban. Like 'WIP'.

The topic of Agile Metrics inevitably comes up in many situations and conversations. For the Scrum practitioners these somehow are a subset of Velocity and Burn ups and downs. Now, there's a whole world out there, that operates with much reacher vocabulary of metrics. Professional Scrum With Kanban (PSK) by Scrum.org brings that world of fantastic Agile Metrics back to Scrum. In this series of posts I will review those metrics using great software - ActionableAgile, provided by fellow PST, Daniel Vacanti.

As a Professional Scrum Trainer for Scrum.org I get to think about the Definition of "Done" and its meaning a lot.

As leaders, we are connected 24/7. Being connected with our mobile devices has meant we’re always available all the time. We have the pressure to move faster. Do more with less time. To our benefit and also to our detriment, we end up doing it.

What exactly is “agile” or even an agile leader? This is one of the biggest problems our industry faces. Ask a room full of people to answer and you may get as many answers. Common ones include “it’s a mindset” or “it’s a software methodology” etc…

A few days ago, I was observing a Sprint Retrospective. The Scrum Team decided to work on the Definition of Done (DoD), identified as the most important topic to adapt for the next Sprint. The discussions were open and animated, when an unexpected discussion emerged during the session.

An Agile mindset is crucial in management roles for organizations that are moving towards Agility. I observed this while working in various organizations and currently am a witness of it while assisting my customers.

There has been so much written about Velocity and its impact on teams yet it is one metric that eludes everyone and keeps cropping up whenever there is discussion around productivity.

Hearing a senior executive announce "We're committed to becoming agile!" is not the bombshell moment it used to be. It no longer indicates a personal revelation or board-room epiphany.