Story points (aka Potato points, Avocado points) are one of the vaguest things in Agile product delivery. They can be super useful, but can also bring a lot of confusion into the team and the company itself (across all levels). On one hand, we can use a derivative of SP — Velocity, to predict delivery and plan milestones. On the other hand, it can be useful as an indicator of the health of the delivery process which might prompt some process improvements.
The missing part of this tool (Story Points) is a common understanding of it. If you put a…
I have the pleasure of working with a distributed Scrum Team. New team, new setup, sort of a new project. We are currently forming our Agile delivery process and on one of the meetings, during backlog refinement to be precise, I got a revelation.
As you all know, the main purpose of the backlog refinement meeting (aka grooming meeting) is to get your upcoming PBI (Product Backlog Item) known better (including DoR (Definition of Ready), story points, potential risk, upcoming priority and so on). Basically the objective is to get things prepared for the next planning session.
So, about that…
How many times you heard the classic — “so you as a team COMMIT to deliver those set of stories”; and suddenly out of nowhere, this sentence became unspeakably horrifying.
So what is a Sprint Goal?
In my opinion, a Sprint Goal has to cover all the roles of a Scrum Team. The whole team has to agree on it, make it explicit, and understandable for everyone.
How do we achieve quality, and what does it really mean anyway? Long story short, the simplest option is to have a mutual agreement (across all levels, vertically and horizontally) on the Definition of Ready and the Definition of done. If all involved parties obey those definitions, it’s very likely that all the following things will be done to a high level
and so on….
Did you ever think what other things can lead us to this promised…
I always believed that the ultimate win for a Scrum Master (team leader/manager) is when the team no longer needs his or her support (and both sides agree on that). Recently I was asking myself the question, should a Scrum Master need to know everything and be a single point of truth?
The Scrum Master needs ensure that people are communicating effectively and that the necessary information is flowing to the people who should be receiving it. …
More and more I realise how important the relationship with the Product Owner, his understanding of the process and his knowledge about the team are, when working in an Agile team.
I can go far enough to say that without this “connection”, it will be very hard to establish a good and successful process and in actual fact, the flip-side can bring a lot of bad feelings and frustration.
Let’s look what the main responsibility of a PO is and what happens if he doesn’t care.
More and more I see that feedback in self-organizing agile teams is becoming a hot topic these days. Being part of an agile community, we have different experiences and understanding as to who should be responsible for this process and how it should look like. Despite the structure of the organization, the questions which need to be answered stay more or less the same.
“If you not able to deliver a working product at the end of your iteration you can’t say that you are Agile team”
I hear this quite often from people working in Agile-ish environments and across the internet. Recently it got me thinking, and I decided to review (once again) the Agile manifesto, Agile principles, Scrum guide and some other stuff.
It’s certainly true that a lot of the core aspects of Scrum and agile focus on delivery like:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
“What is the meaning of your job and what is your main goal?”
If you’re going to ask such kind of questions to business people and development teams, you will often get very different answers. If I were to generalize, I would say that those two “mindsets” often think very differently and are not too keen on explaining their thoughts to another group.
The main cause for this is a lack of the opposite group’s context and an assumption that there is only one truth.
I’ve seen developers complaining about business and business complaining about developers too many times just…
In an Agile world, we believe that our holy grail is self-organized teams (how to get there is a story for another time). That’s cool, because I’m a big fan of this approach. Most of the time they have a lot of seniority and are very mature as a team.
At the same time, an Agile approach is strongly focused on communication and cooperation. From my experience, this is one of the most important factors for project success.
I can see a lot of well-processed cooperation in scrum/kanban/XP teams, which help to solve basic daily issues. …
People, team and software developer. Happy father, husband and owner of the crazy dog :)