What’s a Sprint Goal and Why Does It Matter?
I think it’s essential to ask what a sprint goal is and look deeper into why it matters.
How does a sprint goal drive progress?
Let me share with you some insights from the trenches of Scrum.
Exploring The Tactical Aspect of Scrum
To begin with, I’d like to stress that a sprint goal is a pivotal component of the Scrum framework. 🎯
So, let’s explore what it is, the changes it can bring, and my top three takeaways from the topic.
Ready to uncover the essence of the sprint goal?
Let’s dive right in!
A Tactical Dimension of Scrum
Understanding a Sprint Goal necessitates a clear perception of the vision and the product goal in the Scrum context.
For those well versed in Scrum, we know that a vision is a strategic beacon, guiding us towards a broader objective. At the same time, a product goal serves as an intermediate strategic milestone. They provide a broad direction and a nearer-term aim, respectively.
However, this is where the sprint goal is different. 🎯
This is where we go from strategic to tactical.
Unlike its strategic counterparts, a sprint goal is inherently tactical. It answers questions such as, “What are we doing right now to make progress towards our product goal and our product vision?”
It deals with the nitty-gritty, addressing what we are doing now to move forward towards our product goal and vision. It’s the immediate taskmaster that the team needs to focus on in the present.
A sprint goal serves as a very present and actionable guide, highlighting the immediate tasks at hand for the team. 📈
Concrete Nature of Sprint goals
It’s important to understand the sprint goal clearly.
So, let me explain.
A defining characteristic of a Sprint Goal is its tangibility.
This is a characteristic that sets it apart from all the others. It must be a goal that stakeholders can evaluate at the sprint review and be able to provide concrete and actionable feedback that should resonate on a practical level. 🤲
Feedback cannot be vague or speculative but rather precise, such as “We like this because…” or “We dislike this because…”.
Therefore, a sprint goal is vital to obtain valuable insights from stakeholders, a feedback mechanism that helps the team understand their expectations better.
A Tactical Objective
The sprint goal in action means living in the Moment and is the sprint goal philosophy.
In essence, a sprint goal, at any given moment, is a tactical aim that your team is actively pursuing. A sort of snapshot of what your team is striving towards.
It’s a living, breathing objective that changes with every Sprint, reflecting the ongoing tasks that are shaping the journey towards the ultimate product vision.
It’s about what’s happening and how it contributes to the broader product vision and goal. It provides the team’s immediate focus and helps foster cohesion and motivation. ⏱️
So, there you have it, folks!
To sum up, a Sprint Goal is more than just a task or a target. The tactical compass guides your Scrum team through each Sprint, offering a clear and tangible objective that connects the team’s current efforts with the broader product vision and goal.
Want to learn more about setting impactful Sprint Goals and mastering other elements of Agile and Scrum?
Then my Agile and Scrum courses are just the thing for you!
Let’s continue this journey towards Scrum mastery together.
About NKD Agility
So the question is, what’s the most common mistake or mistakes in Sprint planning? Let’s start with the purpose, right?
Um, Sprint planning’s purpose is to plan the Sprint. Sounds reductive, right? But this purpose is to plan the Sprint.
Um, what I would expect to see happen there is that we’re going to walk into Sprint planning with an ordered, well-understood product backlog as input. We’re probably already going to have an idea of what your Sprint goal is going to be, right? Because you know what your product goal is going to be. You’ve probably just discussed it at your review with your stakeholders and what’s next, right?
Um, and the team probably already has an understanding of all the other work that they’re going to have to bring into the Sprint, as well as working on the Sprint goal.
So then the purpose of the Sprint is to decide what it is we’re doing, how much we think we can do, um, and what does that look like?
So one of the big mistakes that teams make is not having an ordered, understood product backlog walking into Sprint planning. It is the fundamental mistake that almost every team that I work with runs into at some point. And that’s that they’re taking on work because they’re told to take on work, not because they actually understand that work.
If you’re a good indication of this, it’s if your team is sitting doing planning poker during Sprint planning, you’re doing it wrong. You should not be sitting doing planning poker like, “We don’t understand this thing.” What is it? That’s too late. That’s far too late. If you walk into Sprint planning and you pull something off the product backlog and you’re looking at it and the team has never seen it before, they’ve got no clue what this thing is, and they suddenly realise that you need a firewall change and all ops take six weeks to implement a firewall change, you’re just screwed already, right? You can’t bring that into this Sprint. You need to know about that six weeks ago. That’s what refinement’s for.
Refinement is where you push off the understanding of the work, any estimation you want to do, although estimation’s not required by Scrum, right? Sizing, right? Or the sizing you’re going to do, the understanding of what’s in your product backlog, all comes before Sprint planning. And when you walk into Sprint planning, it’s a case of planning the Sprint, not planning all the stuff that you should have planned already before you got there, right?
So that’s one of the biggest mistakes that I see teams making is not already understanding stuff. I’m going to caveat and say somebody will say, “But what if we just received feedback from the stakeholders at Sprint review and there’s a bunch of unknown stuff that comes into Sprint planning?” Awesome! We’re going to have a long Sprint planning this Sprint, right? That’s where we might see planning poker or other estimation techniques or whatever you need in order to gain understanding because some surprise happened, right?
There was a surprise, and we need to deal with that surprise. If every Sprint is a surprise, they’re not doing it right, right? You’re absolutely not doing it right. You need to minimise the chance of surprise. There are some products out there where they get more surprises than other products. That’s cool, right? Roll with it. It’s what works best for you. You’re trying to maximise your effectiveness as a team so we maximise the value that we deliver to the customer. And for that, we need to understand the work that we’re doing. We need to understand, as best we can, the work that is coming towards us.
So that when we get into Sprint planning, we can have a conversation about what we’re working on this Sprint, right? That’s what we’re working on this Sprint. What comes into Sprint planning ends up in your Sprint backlog, and that’s what you’re going to do.
But during every Sprint, you are also working on refinement. You’re also refining things in the product backlog. You’re also gaining more understanding of things that you don’t know yet.
So when you’re planning your Sprint, you also need to carve out how much time do we need to spend understanding the surprises and the unknown in the future so that the next Sprint isn’t going to be on yet another surprise and the Sprint after that isn’t going to be yet another surprise.
Okay, that’s why doing too much is another thing. Taking on too much in the Sprint, right? Because if you take on too much in the Sprint, you’re like, “Oh, well, we don’t have time to do all this refinement,” right?
Because we’re doing all this stuff and we’ve taken on too much and we’re really struggling and we’re having to cut corners. And then we get to the next Sprint planning and we’re like, “Oh, we don’t understand anything that’s in our product backlog.” Okay, we’re screwed again. Okay, we’re going to do the same thing again, and it’s like a death cycle. You also find that teams that end up in that position often don’t meet their Sprint goal. So now they’re unhappy that they’ve not met their Sprint goal because that’s supposed to be a thing, right?
So you’ve got a team that continuously and repeatedly is unable to meet the things that they’ve been asked to commit to every single Sprint. How happy do you think that team is going to be? Not happy at all, right?
Do happy, successful teams make great products, or do sad, unhappy teams make great products? I would suggest that sad, unhappy teams do not make great products. So you don’t want sad, unhappy teams. So stop creating them. Stop building a situation right here where you have these sad, unhappy teams because they’re continuously and repeatedly unable to meet the expectations that they’re setting for themselves, but other people are setting for them as well.
Stop doing that. That’s really bad, right? I mean, that’s Sprint planning. Sprint planning is supposed to set that purpose.
Um, set the purpose for the Sprint. Why are we doing this Sprint? What are we going to do? How are we going to do it, right? And you’ve already failed if you walk into the Sprint and you don’t know the answer to most of those things already, right? Other than surprises, right? Which I’m fully accepting you could walk into a Sprint and, uh, a great example of that is imagine you were working on the Microsoft Teams team, right? Building Microsoft Teams, and you walk into your first Sprint planning after lockdown from COVID, and you’re told immediately that we’ve just gone from, I don’t know, 150,000 simultaneous users to 500,000 simultaneous users practically overnight and that our systems are starting to crumble, right?
That’s where you throw out everything you thought you already knew and you’re going to start again. And perhaps they spent 90% of that Sprint refining what’s next and only a little bit working on the stuff they can.
Right? Sprint planning is all about figuring out what it is you need to do next. But don’t leave it too late. Get your refinement in there first.
Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else Agile, Scrum, or DevOps, then please book a coffee with me through Naked Agility.
So the question is, what’s the most common mistake or mistakes in sprint planning? And let’s start with the purpose, right? Sprint planning’s purpose is to plan the sprint. Sounds reductive, right? But its purpose is to plan the sprint. What I would expect to see happen there is that we’re going to walk into sprint planning with an ordered, well understood product backlog as input. We’re probably already gonna have an idea of what your sprint goal is going to be, right? Because you know what your product goal is going to be. You’ve probably just discussed it at your review with your stakeholders and what’s next, right? And the team probably already has an understanding of all the other work that they’re gonna have to bring into the sprint as well as working on the sprint goal.
So then the purpose of the sprint is to decide what it is we’re doing, how much we think we can do, and what does that look like? So one of the big mistakes that teams make is not having an ordered, understood product backlog walking into sprint planning. It is the fundamental mistake that almost every team that I work with runs into at some point and that’s that they’re taking on work because they’re told to take on work, not because they actually understand that work.
If you’re, a good indication of this is if your team is sitting doing planning poker during sprint planning, you’re doing it wrong. You should not be sitting doing planning poker like we don’t understand this thing. What is it? That’s too late. That’s far too late. If you walk into sprint planning and you pull something off the product backlog and you’re looking at it and the team has never seen it before, they’ve got no clue what this thing is and they suddenly realise that you need a firewall change and all ops take six weeks to implement a firewall change, you’re just screwed already, right? You can’t bring that into this sprint. You need to know about that six weeks ago. That’s what refinement’s for.
Refinement is where you push off the understanding of the work, that any estimation you want to do, although estimation is not required by Scrum, right? Sizing, right? All the sizing you’re going to do, the understanding of what’s in your product backlog, all comes before sprint planning. And when you walk into sprint planning, it’s a case of planning the sprint, not planning all the stuff that you should have planned already before you got there, right?
So that’s one of the biggest mistakes that I see teams making is not already understanding stuff. I’m gonna caveat and say, somebody will say, but what if we just received feedback from the stakeholders at sprint review and there’s a bunch of unknown stuff that comes into sprint planning? Awesome. We’re going to have a long sprint planning this sprint, right? That’s where we might see planning poker or other estimation techniques or whatever you need in order to gain understanding because some surprise happened, right? There was a surprise and we need to deal with that surprise.
If every sprint is a surprise you’re not doing it right, right? You’re absolutely not doing it right. You need to minimise the chance of surprise. There are some products out there where they get more surprises than other products. That’s cool, right? Roll with it. It’s what works best for you. You’re trying to maximise your effectiveness as a team. So we maximise the value that we deliver to the customer. And for that, we need to understand the work that we’re doing. We need to understand as best we can the work that is coming towards us so that when we get into sprint planning, we can have a conversation about what we’re working on this sprint, right?
That’s what we’re working on this sprint is what comes into sprint planning and ends up in your sprint backlog and that’s what you’re gonna do. But during every sprint, you are also working on refinement. You’re also refining things in the product backlog. You’re also gaining more understanding of things that you don’t know yet. So when you’re planning your sprint, you also, that’s the other thing that teams don’t take into account, you also need to carve out how much time do we need to spend understanding the surprises and the unknown in the future so that the next sprint isn’t going to be yet another surprise, and the sprint after that isn’t going to be yet another surprise, okay?
That’s why doing too much is another thing. That taking on too much in the sprint, right? Because if you take on too much in the sprint, you’re like, oh, well, we don’t have time to do all this refinement, right? Because we’re doing all this stuff and we’ve taken on too much and we’re really struggling and we’re having to cut corners and we’re really… And then we get to the next sprint planning and we’re like, oh, we don’t understand anything that’s in our product backlog. Okay, we’re screwed again. Okay, we’ve got to do the same thing again. And it’s like a death cycle.
You also find that teams that end up in that position often don’t meet their sprint goal. So now they’re unhappy that they’ve not met their sprint goal because that’s supposed to be a thing, right? So you’ve got a team that continuously and repeatedly is unable to meet the things that they’ve been asked to commit to every single sprint. How happy do you think that team is going to be? Not happy at all, right? Do happy, successful teams make great products, or do sad, unhappy teams make great products? I would suggest that sad, unhappy teams do not make great products. You don’t want sad, unhappy teams so stop creating them.
Stop building a situation where you have these sad, unhappy teams because they’re unable to continuously and repeatedly unable to meet the expectations that they’re setting for themselves but other people are setting for them as well. Stop doing that shit, that’s really bad, right? That, I mean, that’s sprint planning is supposed to set that purpose, set the purpose for the sprint. Why are we doing this sprint? What are we going to do? How are we going to do it? And you’ve already failed if you walk into the sprint and you don’t know the answer to most of those things already, right? Other than surprises, right?
Which I’m fully accepting you could walk into a sprint and a great example of that is imagine you were working on the Microsoft Teams team, right? Building Microsoft Teams, and you walk into your first sprint planning after lockdown from COVID, and you’re told immediately that we’ve just gone from, I don’t know, 150,000 simultaneous users to 500,000 simultaneous users practically overnight, and that our systems are starting to crumble, right? That’s where you throw out everything you thought you already knew, and you’re gonna start again, and perhaps they spent 90% of that sprint refining what’s next and only a little bit working on the stuff they can right sprint planning is all about figuring out what it is you need to do next, but don’t leave it too late. Get your refinement in there first.
Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments. And if you want to have a chat about this or anything else Agile Scrum or DevOps, then please book a coffee with me through Naked Agility.
Así que la pregunta es, ¿cuál es el error o errores más comunes en la planificación de sprints? Y empecemos por el propósito, ¿no? El propósito de la planificación del sprint es planificar el sprint. Suena reduccionista, ¿verdad? Pero su propósito es planificar el sprint.
Lo que yo esperaría que suceda es que vamos a entrar en la planificación del sprint con un orden, bien entendido backlog del producto como entrada. Probablemente ya vamos a tener una idea de lo que su objetivo del sprint va a ser, ¿verdad? Porque usted sabe lo que su objetivo de producto va a ser. Usted probablemente acaba de discutir en su revisión con las partes interesadas y lo que sigue, ¿verdad?
Y el equipo probablemente ya tiene una comprensión de todo el trabajo que van a tener que traer en el sprint, así como trabajar en el objetivo del sprint. Así que el propósito del sprint es decidir qué es lo que estamos haciendo, cuánto creemos que podemos hacer, y ¿cómo se ve eso?
Así que uno de los grandes errores que los equipos hacen es no tener un orden, la cartera de productos entendido caminar en la planificación del sprint. Es el error fundamental que casi todos los equipos con los que trabajo se encuentra en algún momento y que es que están tomando el trabajo porque se les dice que tomen el trabajo, no porque realmente entienden que el trabajo.
Si usted es, una buena indicación de esto es si su equipo está sentado haciendo la planificación de póker durante la planificación del sprint, lo estás haciendo mal. Usted no debe estar sentado haciendo póker planificación como no entendemos esta cosa. ¿Qué es esto? Es demasiado tarde. Eso es demasiado tarde.
Si entras en la planificación del sprint y sacas algo del backlog del producto y lo estás mirando y el equipo nunca lo ha visto antes, no tienen ni idea de lo que es esta cosa y de repente se dan cuenta de que necesitas un cambio de firewall y todas las operaciones tardan seis semanas en implementar un cambio de firewall, ya estás jodido, ¿verdad? Usted no puede traer que en este sprint. Usted necesita saber acerca de que hace seis semanas. Para eso está el refinamiento.
El refinamiento es donde se empuja fuera de la comprensión del trabajo, que cualquier estimación que desea hacer, aunque la estimación no es requerido por Scrum, ¿verdad? Dimensionamiento, ¿verdad? Todo el tamaño que vas a hacer, la comprensión de lo que está en su backlog del producto, todo viene antes de la planificación del sprint.
Y cuando entras en la planificación del sprint, es un caso de la planificación del sprint, no la planificación de todas las cosas que debería haber planeado ya antes de llegar allí, ¿verdad? Así que ese es uno de los mayores errores que veo que los equipos hacen es no entender ya las cosas.
Voy a advertir y decir, alguien va a decir, pero ¿qué pasa si acabamos de recibir retroalimentación de las partes interesadas en la revisión del sprint y hay un montón de cosas desconocidas que entra en la planificación del sprint? Genial. Vamos a tener un largo sprint de planificación de este sprint, ¿verdad? Ahí es donde podríamos ver el póker de planificación u otras técnicas de estimación o lo que sea necesario con el fin de obtener la comprensión porque alguna sorpresa sucedió, ¿verdad?
Hubo una sorpresa y tenemos que lidiar con esa sorpresa. Si cada sprint es una sorpresa no lo estás haciendo bien, ¿verdad? Absolutamente no lo estás haciendo bien. Es necesario reducir al mínimo la posibilidad de sorpresa. Hay productos con más sorpresas que otros. Eso está bien, ¿no? Déjate llevar. Es lo que funciona mejor para ti.
Estás tratando de maximizar tu eficacia como equipo. Así que maximizamos el valor que entregamos al cliente. Y para eso, tenemos que entender el trabajo que hacemos. Tenemos que entender lo mejor posible el trabajo que viene hacia nosotros para que cuando lleguemos a la planificación del sprint, podamos tener una conversación sobre lo que trabajamos en este sprint, ¿no?
Eso es lo que trabajamos en este sprint, lo que viene en la planificación del sprint y termina en tu sprint backlog y eso es lo que harás. Pero durante cada sprint, también estás trabajando en el refinamiento. También estás refinando cosas en el backlog del producto. También estás ganando más comprensión de las cosas que no sabes todavía.
Así que cuando usted esté planeando su sprint, también, esa es la otra cosa que los equipos no tienen en cuenta, también hay que tallar a cabo la cantidad de tiempo que necesitamos para pasar la comprensión de las sorpresas y lo desconocido en el futuro para que el próximo sprint no va a ser otra sorpresa, y el sprint después de que no va a ser otra sorpresa, ¿de acuerdo?
Por eso hacer demasiado es otra cosa. Que asumir demasiado en el sprint, ¿no? Porque si usted toma demasiado en el sprint, usted es como, oh, bueno, no tenemos tiempo para hacer todo este refinamiento, ¿verdad? Porque estamos haciendo todas estas cosas y hemos tomado demasiado y estamos realmente luchando y estamos teniendo que cortar esquinas y estamos realmente…
Y luego llegamos a la próxima planificación del sprint y estamos como, oh, no entendemos nada de lo que está en nuestro backlog del producto. Bueno, estamos jodidos de nuevo. Bueno, tenemos que hacer lo mismo otra vez. Y es como un ciclo de la muerte. También se encuentra que los equipos que terminan en esa posición a menudo no cumplen con su objetivo del sprint.
Así que ahora están descontentos de que no han cumplido su objetivo del sprint porque se supone que es una cosa, ¿no? Así que tienes un equipo que continúa y repetidamente es incapaz de cumplir con las cosas que se les ha pedido que se comprometan a cada sprint. ¿Qué tan feliz crees que ese equipo va a ser? Nada feliz, ¿verdad?
¿Los equipos felices y exitosos hacen grandes productos, o los equipos tristes e infelices hacen grandes productos? Yo diría que los equipos tristes e infelices no hacen grandes productos. Si no quieres equipos tristes e infelices, deja de crearlos. Deja de crear una situación en la que tienes estos equipos tristes e infelices porque son incapaces de cumplir de forma continua y repetida las expectativas que se están poniendo a sí mismos pero que otras personas también les están poniendo.
Deja de hacer esa mierda, eso es realmente malo, ¿verdad? Eso, quiero decir, que la planificación del sprint se supone que establece que el propósito, establecer el propósito para el sprint. ¿Por qué estamos haciendo este sprint? ¿Qué vamos a hacer? ¿Cómo vamos a hacerlo? Y ya has fallado si entras en el sprint y no sabes la respuesta a la mayoría de esas cosas, ¿verdad?
Aparte de las sorpresas, ¿verdad? Que estoy totalmente de aceptar que usted podría caminar en un sprint y un gran ejemplo de ello es imaginar que estaba trabajando en el equipo de Microsoft Teams, ¿verdad? La construcción de Microsoft Teams, y entras en su primera planificación de sprint después de bloqueo de COVID, y se le dijo de inmediato que acabamos de pasar de, no sé, 150.000 usuarios simultáneos a 500.000 usuarios simultáneos prácticamente durante la noche, y que nuestros sistemas están empezando a desmoronarse, ¿verdad?
Ahí es donde tiras todo lo que pensabas que ya sabías, y vas a empezar de nuevo, y tal vez pasaron el 90% de ese sprint refinando lo que sigue y sólo un poco trabajando en las cosas que pueden planificar bien el sprint se trata de averiguar qué es lo que tienes que hacer a continuación, pero no lo dejes demasiado tarde. Obtenga su refinamiento en primer lugar.
Gracias por ver el vídeo. Si te ha gustado, por favor, como, seguir, y suscribirse. Siempre respondo a los comentarios. Y si quieres tener una charla sobre esto o cualquier otra cosa ágil Scrum o DevOps, entonces por favor reservar un café conmigo a través de agilidad desnuda.
La question est donc de savoir quelle est l’erreur ou les erreurs les plus courantes dans la planification d’un sprint. Commençons par l’objectif, n’est-ce pas ? L’objectif de la planification de sprint est de planifier le sprint. Cela semble réducteur, n’est-ce pas ? Mais son but est de planifier le sprint. Ce que je m’attends à voir se produire, c’est que nous allons aborder la planification du sprint avec un carnet de commandes bien ordonné et bien compris en guise d’intrant. Nous aurons probablement déjà une idée de l’objectif du sprint, n’est-ce pas ? Parce que vous savez quel sera l’objectif de votre produit. Vous venez probablement d’en discuter lors de votre revue avec vos parties prenantes et de ce qui va suivre, n’est-ce pas ?
Et l’équipe a probablement déjà une idée de tous les autres travaux qu’elle devra effectuer au cours du sprint, en plus de travailler sur l’objectif du sprint. Le but du sprint est donc de décider ce que nous faisons, combien nous pensons pouvoir faire, et à quoi cela ressemble. L’une des erreurs commises par les équipes est de ne pas avoir un carnet de commandes ordonné et compris lors de la planification du sprint. C’est l’erreur fondamentale à laquelle se heurtent presque toutes les équipes avec lesquelles je travaille, à un moment ou à un autre, elles prennent du travail parce qu’on leur dit de le faire, et non parce qu’elles comprennent réellement ce travail.
Si votre équipe est assise en train de faire du planning poker pendant la planification du sprint, c’est qu’elle s’y prend mal. Vous ne devriez pas être assis en train de faire du planning poker comme si nous ne comprenions pas cette chose. Qu’est-ce que c’est ? C’est trop tard. C’est beaucoup trop tard. Si vous entrez dans la planification du sprint et que vous sortez quelque chose du backlog du produit, que vous le regardez et que l’équipe ne l’a jamais vu auparavant, qu’elle n’a aucune idée de ce que c’est et qu’elle réalise soudain qu’il faut changer le pare-feu et que tous les ops prennent six semaines pour mettre en œuvre un changement de pare-feu, vous êtes déjà dans la merde, n’est-ce pas ? Vous ne pouvez pas apporter cela dans ce sprint. Vous devez le savoir depuis six semaines. C’est à cela que sert le raffinement. Le raffinement est l’endroit où vous repoussez la compréhension du travail, que toute estimation que vous voulez faire, bien que l’estimation ne soit pas requise par Scrum, n’est-ce pas ? Le dimensionnement, n’est-ce pas ? Tout le dimensionnement que vous allez faire, la compréhension de ce qu’il y a dans votre backlog de produit, tout cela vient avant la planification du sprint.
Et lorsque vous entrez dans la planification du sprint, il s’agit de planifier le sprint, et non pas de planifier toutes les choses que vous auriez déjà dû planifier avant d’y arriver, n’est-ce pas ? C’est donc l’une des plus grosses erreurs que je vois commettre par les équipes, c’est de ne pas comprendre les choses. Je vais mettre en garde et dire, quelqu’un dira, mais que faire si nous venons de recevoir le feedback des parties prenantes lors de la revue de sprint et qu’il y a un tas de choses inconnues qui entrent dans la planification du sprint ? C’est génial. Nous allons avoir un long sprint de planification ce sprint, n’est-ce pas ? C’est là que nous pourrions voir le poker de planification ou d’autres techniques d’estimation ou tout ce dont vous avez besoin pour gagner en compréhension parce qu’une surprise s’est produite, n’est-ce pas ? Il y a eu une surprise et nous devons gérer cette surprise. Si chaque sprint est une surprise, vous ne faites pas les choses correctement, n’est-ce pas ? Absolument pas. Il faut minimiser les risques de surprise.
Pour certains produits, les surprises sont plus nombreuses que pour d’autres. C’est une bonne chose, n’est-ce pas ? Faites avec. C’est ce qui fonctionne le mieux pour vous. Vous essayez de maximiser votre efficacité en tant qu’équipe. Nous maximisons donc la valeur que nous apportons au client. Et pour cela, nous devons comprendre le travail que nous faisons. Nous devons comprendre le mieux possible le travail qui nous attend pour que, lors de la planification du sprint, nous puissions avoir une conversation sur ce sur quoi nous travaillons pour ce sprint, n’est-ce pas ? C’est ce sur quoi nous travaillons ce sprint qui arrive dans la planification du sprint et qui finit dans votre backlog de sprint et c’est ce que vous allez faire.
Mais au cours de chaque sprint, vous travaillez également sur le raffinement. Vous affinez également les éléments du carnet de commandes. Vous apprenez également à mieux comprendre les choses que vous ne connaissez pas encore. Ainsi, lorsque vous planifiez votre sprint, vous devez également, c’est l’autre chose que les équipes ne prennent pas en compte, vous devez également déterminer combien de temps nous devons consacrer à la compréhension des surprises et de l’inconnu à l’avenir afin que le prochain sprint ne soit pas une nouvelle surprise, et que le sprint suivant ne soit pas une nouvelle surprise, d’accord ? C’est pourquoi en faire trop est une autre chose. C’est le fait d’en faire trop pendant le sprint, d’accord ? Parce que si vous en faites trop pendant le sprint, vous vous dites, oh, eh bien, nous n’avons pas le temps de faire tout ce raffinement, n’est-ce pas ? Parce qu’on fait tout ça, qu’on en a trop fait, qu’on a du mal, qu’on doit faire des économies et qu’on est vraiment… Et puis nous arrivons à la planification du prochain sprint et nous nous rendons compte que nous ne comprenons rien à ce qui se trouve dans notre carnet de commandes. Ok, on est encore dans la merde. Il faut refaire la même chose. C’est comme un cycle de mort. On constate également que les équipes qui se retrouvent dans cette situation n’atteignent souvent pas leur objectif de sprint. Elles sont alors mécontentes de ne pas avoir atteint leur objectif de sprint, car c’est censé être le cas, n’est-ce pas ? Vous avez donc une équipe qui, de manière continue et répétée, n’est pas en mesure d’atteindre les objectifs qui lui ont été fixés pour chaque sprint. À quel point pensez-vous que cette équipe sera heureuse ? Pas du tout, n’est-ce pas ?
Les équipes performantes font-elles de bons produits ? Je dirais que les équipes tristes et malheureuses ne font pas de bons produits. Ne créez pas de telles équipes. Évitez de créer une situation où elles sont incapables de répondre aux attentes. Arrêtez de faire cela, c’est mauvais, n’est-ce pas ? C’est la planification du sprint qui fixe l’objectif. Pourquoi faisons-nous ce sprint ? Que faisons-nous ? Comment le faisons-nous ? Et vous avez déjà échoué si vous entrez dans le sprint et que vous ne connaissez pas déjà la réponse à la plupart de ces questions, n’est-ce pas ? À part les surprises, n’est-ce pas ? Je suis tout à fait d’accord pour dire qu’il est possible d’arriver à un sprint et un bon exemple de cela est d’imaginer que vous travaillez dans l’équipe de Microsoft Teams, n’est-ce pas ? En construisant Microsoft Teams, vous arrivez à votre première planification de sprint après le verrouillage de COVID, et on vous dit immédiatement que nous venons de passer de, je ne sais pas, 150 000 utilisateurs simultanés à 500 000 utilisateurs simultanés pratiquement du jour au lendemain, et que nos systèmes commencent à s’effondrer, n’est-ce pas ? C’est là que vous jetez tout ce que vous pensiez déjà savoir, et vous allez recommencer, et peut-être qu’ils ont passé 90% de ce sprint à affiner ce qui va suivre et seulement un petit peu à travailler sur les choses qu’ils peuvent faire. Il faut commencer par affiner les choses.
Merci d’avoir regardé cette vidéo. Si vous l’avez appréciée, n’hésitez pas à l’aimer, à la suivre et à vous abonner. Je réponds toujours aux commentaires. Et si vous voulez discuter de ce sujet ou de tout autre sujet concernant Agile Scrum ou DevOps, n’hésitez pas à prendre un café avec moi par l’intermédiaire de Naked Agility.
ãã㧠質åã ãã ã¹ããªã³ã è¨ç»ã§æããã ããééãã ãã¹ã¯ ä½ã ãããï¼ ã¾ãã ç®çãã èãã¿ããã ã¹ããªã³ããã© ã³ãã³ ã°ã®ç®çã¯ã ã¹ããªã³ãã è¨ç»ã ããã¨ã ã éå
çèãã ãã ã ãï¼ãããã ãã®ç® çã¯ã¹ã㪠ã³ããè¨ ç»ãããã¨ã ã ã¹ããªã³ ãã»ãã©ã³ã ã³ã°ã§æå¾
ããããã¨ã¯ã é åºããç 解ãã ãããã㯠ãããã¯ãã°ã ã¤ã³ãã¨ãã¦ã ã¹ããªã³ ãã»ãã©ã³ã ã³ã°ã«å
¥ã ã¨ãããã¨ã ã ã¹ããªã³ ãã®ã´ã¼ã«ã¯ã ããããã§ã« åãã£ã¦ ããã¯ãã ã ãªããªãã ããªã ã¯è£½åã®ã´ã¼ ã«ãç¥ã£ ã¦ããããã ã ããªã ã¯ãããã ã¹ãã¼ã¯ãã«ã ã¼ã¨ã® ã¬ãã¥ã¼ã§ã ãã«ã¤ ãã¦è°è«ã ãã¨ãã ã§ããããã 次ã«ä½ã ãããã«ã¤ã㦠ãè°è«ãã ã¨ãã ã§ãããï¼ ãã㦠ãã¼ã ã¯ã ã¹ã㪠ã³ãã´ã¼ã« ã«åãçµ ãã ãã§ãªãã ã¹ããªã³ã ã«æã¡ è¾¼ã¾ãªãã ã°ãããªãä» ã®ä½æ¥ ã«ã¤ãã¦ãã ãã§ã«ç解 ãã¦ã ãã¯ãã ã ã ããã¹ã ãªã³ã ã®ç®çã¯ã ããããã㧠ãã㨠æãã®ãã ããã¦ã ãã¯ã©ã®ãã㪠ãã®ãªã®ã ã決ã ãã¨ã ã ã ããã ãã¼ã ãç¯ãå¤ã ãªééã ã®ã²ã¨ã¤ã¯ã ã¹ã㪠ã³ãã»ãã© ã³ãã³ã° ã«å
¥ãåã«ã é åºç«ã¦ã¦ç 解ãã ãããã㯠ãããã¯ãã°ã ãã£ã¦ã㪠ããã¨ã ã ããã¯ã ç§ãä¸ç·ã«ä»äº ãããã» ã¼ãã¹ã¦ã®ã ã¼ã ã ã©ããã§é¥ã æ ¹æ¬ç㪠ééãã§ããã ä»äºãå¼ãå ããã ãã«è¨ããã ããä» ãå¼ãå ãã¦ãã ã®ã§ãã£ã¦ã ãã®ä» äºãå®éã«ç 解ãã¦ãã ããã§ã¯ãªãã ããã ã¹ã㪠ã³ãã»ãã© ã³ãã³ã° ä¸ã«ãã¼ã ãã ã©ã³ã ã³ã°ã«å
¥ãã¨ã ããã¦ããã©ã®ããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããããã
Pytanie brzmi więc, jaki jest najczęstszy błąd lub błędy w planowaniu sprintu? Zacznijmy od celu, prawda? Celem planowania sprintu jest zaplanowanie sprintu. Brzmi redukcyjnie, prawda? Ale jego celem jest zaplanowanie sprintu. Spodziewałbym się, że do planowania sprintu przystąpimy z uporządkowanym, dobrze zrozumianym rejestrem produktu jako danymi wejściowymi. Prawdopodobnie mamy już pojęcie, jaki będzie cel sprintu, prawda? Ponieważ wiesz, jaki będzie cel Twojego produktu. Prawdopodobnie właśnie omówiłeś go podczas przeglądu z interesariuszami i co dalej, prawda? A zespół prawdopodobnie już rozumie wszystkie inne prace, które będą musieli wykonać w sprincie, a także pracuje nad celem sprintu. Celem sprintu jest więc podjęcie decyzji o tym, co robimy, ile naszym zdaniem możemy zrobić i jak to wygląda? Tak więc jednym z największych błędów popełnianych przez zespoły jest brak uporządkowanego, zrozumiałego rejestru produktowego przed przystąpieniem do planowania sprintu. Jest to podstawowy błąd, który popełnia prawie każdy zespół, z którym pracuję, a polega on na tym, że podejmują się pracy, ponieważ kazano im ją podjąć, a nie dlatego, że faktycznie ją rozumieją. Dobrym wskaźnikiem tego jest to, że jeśli Twój zespół siedzi i planuje pokera podczas planowania sprintu, to robisz to źle. Nie powinieneś siedzieć przy planowaniu pokera, jakbyśmy nie rozumieli tej rzeczy. Co to jest? To za późno. O wiele za późno. Jeśli planujesz sprint i wyciągasz coś z zaległości produktowych i patrzysz na to, a zespół nigdy wcześniej tego nie widział, nie mają pojęcia, co to jest i nagle zdają sobie sprawę, że potrzebujesz zmiany zapory ogniowej, a wszystkie operacje potrzebują sześć tygodni na wdrożenie zmiany zapory ogniowej, to już masz przechlapane, prawda? Nie możesz tego wnieść do tego sprintu. Musisz wiedzieć o tym sześć tygodni temu. Do tego właśnie służy udoskonalanie. Dopracowanie to miejsce, w którym odsuwasz zrozumienie pracy, którą chcesz oszacować, chociaż szacowanie nie jest wymagane przez Scrum, prawda? Wymiarowanie, prawda? Cały dobór rozmiaru, który zamierzasz wykonać, zrozumienie tego, co znajduje się w Twoim rejestrze produktu, wszystko to ma miejsce przed planowaniem sprintu. A kiedy przystępujesz do planowania sprintu, jest to przypadek planowania sprintu, a nie planowania wszystkich rzeczy, które powinieneś był zaplanować jeszcze przed jego rozpoczęciem, prawda? Tak więc jednym z największych błędów popełnianych przez zespoły jest niezrozumienie pewnych rzeczy. Zastrzegę i powiem, że ktoś powie, ale co jeśli właśnie otrzymaliśmy informacje zwrotne od interesariuszy podczas przeglądu sprintu i jest kilka nieznanych rzeczy, które wchodzą w planowanie sprintu? Super. Będziemy długo planować ten sprint, prawda? To właśnie tam możemy zobaczyć planowanie pokera lub inne techniki szacowania lub cokolwiek, czego potrzebujesz, aby uzyskać zrozumienie, ponieważ wydarzyła się jakaś niespodzianka, prawda? Pojawiła się niespodzianka i musimy sobie z nią poradzić. Jeśli każdy sprint jest niespodzianką, to nie robisz tego dobrze, prawda? Absolutnie nie robisz tego dobrze. Musisz zminimalizować szansę na zaskoczenie. Istnieją produkty, w których niespodzianek jest więcej niż w innych. To jest fajne, prawda? Nie przejmuj się tym. To jest to, co działa najlepiej dla Ciebie. Starasz się zmaksymalizować swoją efektywność jako zespół. Maksymalizujemy więc wartość, którą dostarczamy klientowi. W tym celu musimy zrozumieć pracę, którą wykonujemy. Musimy jak najlepiej zrozumieć pracę, która do nas dociera, abyśmy mogli porozmawiać o tym, nad czym pracujemy w tym sprincie, kiedy przystępujemy do planowania sprintu, prawda? To, nad czym pracujemy w tym sprincie, jest tym, co pojawia się w planowaniu sprintu i kończy się w zaległościach sprintu i to jest to, co zamierzasz zrobić. Ale podczas każdego sprintu pracujesz również nad udoskonalaniem. Dopracowujesz również rzeczy w rejestrze produktu. Zdobywasz także więcej wiedzy na temat rzeczy, których jeszcze nie wiesz. Więc kiedy planujesz swój sprint, musisz także, to jest inna rzecz, której zespoły nie biorą pod uwagę, musisz także określić, ile czasu musimy poświęcić na zrozumienie niespodzianek i nieznanego w przyszłości, aby następny sprint nie był kolejną niespodzianką, a następny sprint nie będzie kolejną niespodzianką, dobrze? Właśnie dlatego robienie zbyt wiele to kolejna rzecz. To branie na siebie zbyt wiele w sprincie, prawda? Bo jeśli weźmiesz na siebie zbyt wiele w sprincie, to myślisz, no cóż, nie mamy czasu na te wszystkie udoskonalenia, prawda? Ponieważ robimy te wszystkie rzeczy i wzięliśmy na siebie zbyt wiele i naprawdę walczymy i musimy iść na skróty i naprawdę… A potem przystępujemy do planowania kolejnego sprintu i stwierdzamy, że nie rozumiemy niczego, co znajduje się w naszym rejestrze produktu. Ok, znowu mamy przechlapane. Znów musimy robić to samo. To jak cykl śmierci. Okazuje się również, że zespoły, które znajdują się w takiej sytuacji, często nie osiągają celu sprintu. Więc teraz są niezadowoleni, że nie osiągnęli celu sprintu, ponieważ to powinno być coś, prawda? Masz więc zespół, który stale i wielokrotnie nie jest w stanie sprostać zadaniom, do których został poproszony w każdym sprincie. Jak myślisz, jak szczęśliwy będzie ten zespół? Wcale nie szczęśliwy, prawda? Czy szczęśliwe, odnoszące sukcesy zespoły tworzą świetne produkty, czy smutne, nieszczęśliwe zespoły tworzą świetne produkty? Sugerowałbym, że smutne, nieszczęśliwe zespoły nie tworzą świetnych produktów. Nie chcesz smutnych, nieszczęśliwych zespołów, więc przestań je tworzyć. Przestań budować sytuację, w której masz te smutne, nieszczęśliwe zespoły, ponieważ nie są one w stanie stale i wielokrotnie spełniać oczekiwań, które sami sobie stawiają, ale także inni ludzie. Przestań robić to gówno, to jest naprawdę złe, prawda? To znaczy, planowanie sprintu ma na celu ustalenie tego celu, ustalenie celu sprintu. Dlaczego robimy ten sprint? Co zamierzamy zrobić? Jak zamierzamy to zrobić? I już poniosłeś porażkę, jeśli wchodzisz do sprintu i nie znasz odpowiedzi na większość z tych rzeczy, prawda? Poza niespodziankami, prawda? W pełni akceptuję, że możesz wejść do sprintu, a świetnym tego przykładem jest wyobrażenie sobie, że pracujesz w zespole Microsoft Teams, prawda? Budujesz Microsoft Teams i wchodzisz w swój pierwszy sprint planowania po blokadzie od COVID i od razu dowiadujesz się, że właśnie przeszliśmy od, nie wiem, 150 000 jednoczesnych użytkowników do 500 000 jednoczesnych użytkowników praktycznie z dnia na dzień, a nasze systemy zaczynają się rozpadać, prawda? To jest moment, w którym wyrzucasz wszystko, co myślałeś, że już wiesz, i zaczynasz od nowa, i być może spędzili 90% tego sprintu na dopracowywaniu tego, co będzie dalej, a tylko trochę pracując nad rzeczami, które mogą planowanie sprintu polega na ustaleniu, co musisz zrobić dalej, ale nie zostawiaj tego za późno. Dopracuj to najpierw. Dzięki za obejrzenie filmu. Jeśli Ci się podobało, polub, śledź i subskrybuj. Zawsze odpowiadam na komentarze. A jeśli chcesz porozmawiać o tym lub o czymkolwiek innym związanym z Agile Scrum lub DevOps, umów się ze mną na kawę za pośrednictwem Naked Agility.
Então, a pergunta é: qual é o erro ou erros mais comuns no planejamento de sprint? E vamos começar com o objetivo, certo? O objetivo do planejamento de sprint é planejar o sprint. Parece redutor, certo? Mas seu objetivo é planejar o sprint. O que eu esperaria ver acontecer é que vamos entrar no planejamento do sprint com um backlog de produtos ordenado e bem compreendido como entrada. Provavelmente já teremos uma ideia de qual será a meta do sprint, certo? Porque você sabe qual será a meta do seu produto. Provavelmente, acabou de discuti-la em sua revisão com as partes interessadas e o que vem a seguir, certo?
E a equipe provavelmente já tem uma compreensão de todo o outro trabalho que terá de fazer no sprint, além de trabalhar na meta do sprint. Portanto, o objetivo do sprint é decidir o que estamos fazendo, o quanto achamos que podemos fazer e como será isso. Portanto, um dos grandes erros que as equipes cometem é não ter um backlog de produtos ordenado e compreendido durante o planejamento do sprint. Esse é o erro fundamental que quase todas as equipes com as quais trabalho cometem em algum momento, ou seja, estão assumindo o trabalho porque lhes foi dito para assumi-lo, e não porque realmente entendem esse trabalho.
Uma boa indicação disso é que, se a sua equipe está sentada fazendo planning poker durante o planejamento do sprint, ela está fazendo isso errado. Você não deveria estar sentado fazendo pôquer de planejamento como se não entendêssemos isso. O que é isso? Isso é tarde demais. É tarde demais. Se você entra no planejamento do sprint e tira algo do backlog do produto e está olhando para ele e a equipe nunca o viu antes, não tem a menor ideia do que é isso e, de repente, percebe que precisa de uma alteração no firewall e que todas as operações levam seis semanas para implementar uma alteração no firewall, você já está ferrado, certo? Você não pode trazer isso para esse sprint. Você precisa saber disso há seis semanas. É para isso que serve o refinamento.
O refinamento é onde você empurra a compreensão do trabalho, que qualquer estimativa que você queira fazer, embora a estimativa não seja exigida pelo Scrum, certo? Dimensionamento, certo? Todo o dimensionamento que você vai fazer, a compreensão do que está no seu backlog de produtos, tudo isso vem antes do planejamento do sprint. E quando você entra no planejamento do sprint, é o caso de planejar o sprint, e não planejar todas as coisas que você já deveria ter planejado antes de chegar lá, certo? Portanto, esse é um dos maiores erros que vejo as equipes cometerem: não entender as coisas.
Vou fazer uma ressalva e dizer, alguém dirá, mas e se acabamos de receber feedback das partes interessadas na revisão do sprint e há um monte de coisas desconhecidas que entram no planejamento do sprint? É fantástico. Teremos um longo planejamento de sprint neste sprint, certo? É aí que podemos ver o pôquer de planejamento ou outras técnicas de estimativa ou o que quer que seja necessário para obter entendimento porque alguma surpresa aconteceu, certo? Houve uma surpresa e precisamos lidar com ela. Se cada sprint for uma surpresa, você não está fazendo isso direito, certo? Com certeza não está fazendo direito. É preciso minimizar a chance de surpresa.
Em alguns produtos, há mais surpresas do que em outros. Isso é legal, certo? Faça isso. É o que funciona melhor para você. Você está tentando maximizar sua eficácia como equipe. Assim, maximizamos o valor que entregamos ao cliente. E, para isso, precisamos entender o trabalho que estamos fazendo. Precisamos entender da melhor forma possível o trabalho que está chegando até nós para que, quando entrarmos no planejamento do sprint, possamos conversar sobre o que estamos fazendo neste sprint, certo? O que estamos trabalhando neste sprint é o que entra no planejamento do sprint e acaba no backlog do sprint, e é isso que você vai fazer.
Mas durante cada sprint, você também está trabalhando no refinamento. Você também está refinando as coisas no backlog do produto. Você também está adquirindo mais conhecimento sobre coisas que ainda não sabe. Portanto, ao planejar o sprint, você também, e essa é a outra coisa que as equipes não levam em conta, você também precisa definir quanto tempo precisamos gastar para entender as surpresas e o desconhecido no futuro, de modo que o próximo sprint não seja mais uma surpresa, e o sprint seguinte não seja mais uma surpresa, certo? É por isso que fazer demais é outra coisa. É preciso assumir muito no sprint, certo? Porque, se você se ocupa demais no sprint, você pensa: “Ah, bem, não temos tempo para fazer todo esse refinamento, certo? Porque estamos fazendo todas essas coisas e assumimos muitas coisas e estamos realmente lutando e tendo que cortar custos e estamos realmente… E então chegamos ao planejamento do próximo sprint e pensamos: “Ah, não entendemos nada do que está no nosso backlog de produtos. Pronto, estamos ferrados de novo. Temos que fazer a mesma coisa de novo.” E isso é como um ciclo de morte.
Você também percebe que as equipes que acabam nessa posição geralmente não atingem a meta do sprint. Então, agora elas ficam insatisfeitas por não terem atingido a meta do sprint, porque isso deveria ser uma coisa, certo? Portanto, você tem uma equipe que, continuamente, não consegue cumprir as coisas com as quais foi solicitada a se comprometer a cada sprint. Quão feliz você acha que essa equipe vai ficar? Nem um pouco feliz, certo? Equipes criam produtos excelentes? Equipes tristes e infelizes não produzem produtos excelentes. Pare de criá-las. Pare de criar uma situação em que você tenha essas equipes porque elas são incapazes de atender às expectativas. Pare de fazer isso, é ruim.
O planejamento do sprint deve definir o objetivo. Por que estamos fazendo esse sprint? O que vamos fazer? Como vamos fazer? E você já fracassou se chegar ao sprint e não souber a resposta para a maioria dessas coisas, certo? Com exceção das surpresas, certo? E um ótimo exemplo disso é imaginar que você esteja trabalhando na equipe do Microsoft Teams, certo? Criando o Microsoft Teams, e você entra no seu primeiro planejamento de sprint após o lockdown da COVID, e é informado imediatamente que acabamos de passar de, sei lá, 150.000 usuários simultâneos para 500.000 usuários simultâneos praticamente da noite para o dia, e que nossos sistemas estão começando a desmoronar, certo? É nesse momento que você joga fora tudo o que achava que já sabia e vai começar de novo, e talvez eles tenham passado 90% desse sprint refinando o que vem a seguir e apenas um pouco trabalhando nas coisas que podem fazer.
O planejamento do sprint tem tudo a ver com descobrir o que você precisa fazer a seguir, mas não deixe para depois. Faça seu refinamento primeiro. Obrigado por assistir ao vídeo. Se você gostou, por favor, curta, siga e se inscreva. Eu sempre respondo aos comentários. E se você quiser conversar sobre isso ou qualquer outra coisa sobre Agile Scrum ou DevOps, agende um café comigo por meio da Naked Agility.
Vprašanje je, katera je najpogostejša napaka ali napake pri načrtovanju sprinta? Začnimo z namenom, kajne? Namen načrtovanja sprinta je načrtovati sprint. Sliši se reduktivno, kajne? Toda njegov namen je načrtovati sprint. Pričakoval bi, da se bo pri tem zgodilo to, da bomo v načrtovanje sprinta vstopili z urejenim, dobro razumljenim seznamom izdelkov kot vhodnim podatkom. Verjetno bomo že imeli idejo o tem, kakšen bo cilj vašega sprinta, kajne? Ker veste, kakšen bo cilj vašega izdelka. Verjetno ste se o tem pravkar pogovarjali na pregledu z zainteresiranimi stranmi in kaj bo sledilo, kajne? In ekipa verjetno že razume vse drugo delo, ki ga bo morala opraviti v sprintu, kot tudi delo na cilju sprinta. Torej je potem namen sprinta, da se odločimo, kaj delamo, koliko mislimo, da lahko naredimo, in kako je to videti?
Ena od velikih napak, ki jih delajo ekipe, je, da pri načrtovanju sprinta nimajo urejenega in razumljivega seznama izdelkov. To je temeljna napaka, s katero se na neki točki sreča skoraj vsaka ekipa, s katero delam, in sicer da se lotijo dela, ker jim je bilo rečeno, naj se ga lotijo, in ne zato, ker to delo dejansko razumejo. Dober pokazatelj tega je, če vaša ekipa med načrtovanjem sprinta sedi in dela načrtovalni poker, to počnete narobe. Ne smete sedeti in se ukvarjati s pokrom načrtovanja, kot da te stvari ne razumemo. Kaj je to? To je prepozno. To je veliko prepozno. Če pridete na načrtovanje sprinta in potegnete nekaj iz seznama izdelkov in to gledate, ekipa pa tega še nikoli ni videla, nima pojma, kaj je to, in nenadoma spozna, da potrebujete spremembo požarnega zidu, vsi operaterji pa potrebujejo šest tednov, da izvedejo spremembo požarnega zidu, ste že v riti, kajne? Tega ne morete vnesti v ta sprint. Za to morate vedeti že pred šestimi tedni. Za to so potrebne izboljšave. Izboljšanje je tisto, pri katerem se odmaknete od razumevanja dela, da bi opravili kakršno koli oceno, čeprav Scrum ocene ne zahteva, kajne? Določanje velikosti, kajne? Vse določanje velikosti, ki ga boste opravili, razumevanje tega, kaj je v vaši košarici izdelkov, se opravi pred načrtovanjem sprinta. In ko začnete načrtovati sprint, gre za načrtovanje sprinta, ne pa za načrtovanje vseh stvari, ki bi jih morali načrtovati, še preden ste prišli tja, kajne? To je ena največjih napak, ki jih delajo ekipe, in sicer, da stvari ne razumejo že prej.
Opozoril bom, da bo nekdo rekel, kaj pa če smo pravkar prejeli povratne informacije od zainteresiranih strani na pregledu sprinta in je v načrtovanje sprinta vključenih še kup neznanih stvari? Odlično. Ta sprint bomo načrtovali dolgo, kajne? To je tisto, kjer bomo morda videli poker načrtovanja ali druge tehnike ocenjevanja ali karkoli, kar potrebujete, da bi pridobili razumevanje, ker se je zgodilo kakšno presenečenje, kajne? Zgodilo se je presenečenje in to presenečenje moramo obravnavati. Če je vsak sprint presenečenje, tega ne počnete prav, kajne? Nikakor ne delate prav. Morate čim bolj zmanjšati možnost presenečenja. Pri nekaterih izdelkih je več presenečenj kot pri drugih. To je super, kajne? Sprijaznite se s tem. To je tisto, kar vam najbolj ustreza. Poskušate čim bolj povečati svojo učinkovitost kot ekipa. Tako maksimiziramo vrednost, ki jo zagotavljamo stranki. Za to moramo razumeti delo, ki ga opravljamo. Čim bolje moramo razumeti delo, ki nam prihaja naproti, da se lahko, ko začnemo načrtovati sprint, pogovorimo o tem, kaj bomo delali v tem sprintu, kajne? To, na čem delamo v tem sprintu, je tisto, kar pride v načrtovanje sprinta in se konča v vašem sprint backlogu, in to je tisto, kar boste naredili. Toda med vsakim sprintom se ukvarjate tudi z izpopolnjevanjem. Izboljšujete tudi stvari v zbirki izdelkov. Prav tako pridobivate boljše razumevanje stvari, ki jih še ne poznate.
Ko torej načrtujete sprint, morate tudi, to je druga stvar, ki je ekipe ne upoštevajo, določiti, koliko časa moramo porabiti za razumevanje presenečenj in neznanega v prihodnosti, da naslednji sprint ne bo še eno presenečenje in naslednji sprint ne bo še eno presenečenje, jasno? Zato je pretiravanje druga stvar. To, da si v sprintu vzamete preveč dela, kajne? Ker če se v sprintu lotiš preveč stvari, si rečeš, aha, nimamo časa za vse te izboljšave, kajne? Ker delamo vse te stvari in smo se lotili preveč, se res borimo in moramo skrajšati pot in smo res… In potem pridemo do načrtovanja naslednjega sprinta in si rečemo, oh, ničesar ne razumemo, kar je v našem seznamu izdelkov. Okej, spet smo v škripcih. Okej, spet moramo narediti isto stvar. In to je kot smrtni krog. Ugotovite tudi, da ekipe, ki se znajdejo v takšnem položaju, pogosto ne dosežejo cilja sprinta. Zdaj so nezadovoljne, ker niso dosegle cilja sprinta, saj naj bi bilo to nekaj takega, kajne? Tako imate ekipo, ki nenehno in večkrat ne more izpolniti stvari, za katere se je morala zavezati v vsakem sprintu. Kaj mislite, kako srečna bo ta ekipa? Sploh ne, kajne?
Ali srečne, uspešne ekipe ustvarjajo odlične izdelke ali žalostne, nesrečne ekipe ustvarjajo odlične izdelke? Menim, da žalostne, nesrečne ekipe ne ustvarjajo odličnih izdelkov. Ne želite žalostnih in nesrečnih ekip, zato jih nehajte ustvarjati. Prenehajte ustvarjati razmere, v katerih imate te žalostne in nesrečne ekipe, ker ne morejo nenehno in večkrat izpolniti pričakovanj, ki jih postavljajo sami, pa tudi drugi ljudje jih postavljajo zanje. Prenehajte delati to sranje, to je res slabo, kajne? Načrtovanje sprinta naj bi določilo ta namen, določilo namen sprinta. Zakaj delamo ta sprint? Kaj bomo naredili? Kako bomo to naredili? In če že vstopite v sprint in ne poznate odgovora na večino teh stvari, vam je že spodletelo, kajne? Razen presenečenj, kajne? Popolnoma se strinjam, da lahko pridete na sprint, in odličen primer za to je, da si predstavljate, da delate v ekipi Microsoft Teams, kajne? Gradite Microsoft Teams in pridete na svoj prvi sprint, ki ga načrtujete po tem, ko vas je COVID zaprl, in vam takoj povejo, da smo se s 150.000 hkratnih uporabnikov praktično čez noč povzpeli na 500.000 hkratnih uporabnikov in da naši sistemi začenjajo razpadati, kajne? Takrat zavržete vse, kar ste mislili, da že veste, in začnete znova, in morda so 90 % tega sprinta porabili za izpopolnjevanje tega, kaj bo sledilo, in le malo delali na stvareh, ki jih lahko. Prav na načrtovanje sprinta je v tem, da ugotovite, kaj morate narediti naprej, vendar tega ne pustite prepozno. Najprej se lotite izpopolnjevanja.
Hvala za ogled videoposnetka. Če vam je bil všeč, sledite in se naročite. Vedno odgovorim na komentarje. Če pa se želite pogovoriti o tem ali čem drugem o agilnem Scrumu ali DevOps-u, se naročite na kavo z mano prek Naked Agility.
É£ä¹é® é¢æ¥äº,å²åº 计åä¸æ常 è§ççé误æ¯ä»ä¹?让æä»¬ä» ç®ç说起,对å?å²åºè®¡åç ç®çæ¯è§åå²åº。åèµ·æ¥ å¾ç®å,对å?ä½å®çç®çå°±æ¯è®¡åå²åº。æå¸æ å¨å²åºè®¡åä¸ç到ç,æ们å°å¸¦çä¸ä¸ªæåº,æ¸
æ°ç产å积å(product backlog)è¿å
¥å²åºè®¡å。æ们å¯è½å·²ç»ç¥éä½ çå²åºç®æ æ¯ä»ä¹äº,对å?å ä¸ºä½ ç¥éä½ ç产åç®æ æ¯ä»ä¹。ä½ å¯è½åå在è¯å®¡ä¸ä¸å©çç¸å…³è
讨论è¿,æ¥ä¸æ¥è¦åä»ä¹,对å?å¢éå¯è½å·²ç»äºè§£äºä»ä»¬åœ¨å²åºé¶æ®µéè¦å®æçææå
¶å·¥ä½,以åå²åºç®æ 。å æ¤,å²åºçç®çå°±æ¯å³å®æ们è¦åä»ä¹,æ们认为æ们è½åå¤å°,è¿çèµ·æ¥åä»ä¹?å¢éæç¯çä¸ä¸ªå¤§é误就æ¯å¨å²åºè®¡åä¸æ²¡æä¸ä¸ªæåº,æ¸
æ°ç产å积å。è¿æ¯æå·¥ä½è¿ççåä¹æ¯ä¸ªå¢éé½ä¼éå°ççå°çççç。é£å°±æ¯ä»ä»¬æ¥æå·¥ä½æ¯å 为ä»ä»¬è¢«åç¥è¦æ¥æå·¥。ä½,èä¸æ¯å 为ä»ä»¬çæ£äºè§£è¿äºå·¥ä½。å¦æä½ çå¢éå¨å²åºè®¡åæé´åçå计åæå
ç,é£å°±è¯´æä½ åéäº。ä½ ä¸åºè¯¥åå¨é£éå计åæå
,å°±åæ们ä¸æç½è¿ä»¶äºä¸æ ·。这æ¯ä»ä¹?太è¿äº。太æäº。å¦æä½ èµ°è¿å²åºè®¡å,ä»äº§å积åä¸æ½åºä¸äºä¸,西,ä½ æ£å¨çå®,èå¢é以åä»æªè§è¿å®,ä»ä»¬æ ¹æ¬ä¸ç¥éè¿æ¯ä»ä¹ä¸è¥¿,ç¶åä»ä»¬çªç¶æè¯å°ä½ éè¦ä¿®æ¹é²ç«å¢,èææçè¿ç»´äººåé½éè¦å
å¨çæ¶é´æ¥å®æ½é²ç«å¢ä¿®æ¹,é£ä½ 就已ç»å®èäº,对å?ä½ ä¸è½æè¿ç§æ
åµå¸¦å
¥å²åºé¶æ®µ。ä½ éè¦å¨å
å¨åå°±ç¥éã这å°±æ¯å®åçç®ç。ç»åæ¯ä½ æ¨ç¿»å¯¹å·¥ä½çç解çç,ä¹å°±æ¯ä½ æ³åç。ä»»ä½ä¼°ç®,尽管Scrum 并ä¸è¦æ±ä¼°ç®,对å?ç¡®。å®è§æ¨¡,对å?ä½ è¦åçææ大å°è°æ´,对产å积。åä¸å
容çç解,é½æ¯å¨å²åºè®¡åä¹åè¿è¡ç。èå½ä½ è¿å
¥å²åºè®¡åæ¶,ä½ è¦åçæ¯è§åå²åº,èä¸æ¯è§。åææä½ åºè¯¥å¨å²åºåå°±è§å好çç,对å?æ以,这æ¯æçå°å¢éç¯çæ大é误ä¹ä¸,å ä¸ä»¬è¿ä¸äºè§£è¿äºä¸è¥¿。ææ³è¯´çæ¯,æ人ä¼è¯´,ä½å¦ææ们ååå¨å²åºè¯å®¡ä¸æ¶,到äºå©çç¸å…³è
çåé¦,èå²åºè®¡åä¸åæä¸å æªç¥çç。好æäº。æ们è¿æ¬¡å²åºè®¡åçæ¶é´ä¼å¾é¿,对å?这å°±æ¯æ们å¯è½ä¼çå°è§åæå
æå
¶ä»ä¼°ç®ææ¬é误,è¿å¾é
·,对å?éå®å»å§。这å°±æ¯æéåä½ çæ¹æ³。ä½ä¸ºä¸ä¸ªå¢é,ä½ ä»¬è¦åªåå®ç°æçæ大å。å æ¤,æ们è¦æ大é度å°ä¸ºå®¢æåé ä»·å¼。为æ¤,æ们éè¦äºè§£æ们æ£å¨åçç。æ们éè¦å°½å¯è½äºè§£æ们æ£å¨åçç,è¿æ ·å½æ们è¿å²åºè®¡åæ¶,æ们就è½å°±è¿ä¸ªå²åºçå·¥ä½å
容è¿è¡å¯¹è¯,对å?æ们这个å²åºè¦åçå·¥ä½å°±æ¯è¿å
¥å²åºè®¡å并æç»è¿å
¥å²。åºç§¯åçå·¥ä½,è¿å°±æ¯ä½ è¦åç。ä½å¨æ¯ä¸ªå²åºæé´,ä½ ä¹å¨åªåå®å。ä½ ä¹å¨å®å产å积åä¸çå
容。åæ¶,ä½ ä¹ä¼å¯¹èªå·±è¿ä¸äºè§£çç,æ
ææ´å¤ç解。å æ¤,å½ä½ 计åå²åºæ¶,ä½ è¿éè¦èèå¢é没æè。èå°çå¦ä¸ä»¶äº,é£å°±æ¯æ们éè¦è±å¤å°æ¶é´å»äºè§£æªæ¥çç。ååæªç¥,以便ä¸ä¸ä¸ªå²åºä¸ä¼åææå,ä¹åçå²åºä¹ä¸ä¼åææ。å,æç½å?这å°±æ¯ä¸ºä»ä¹å太å¤æ¯å¦ä¸ä»¶äº。在å²åºé¶æ®µæ¿æ
太å¤,对å?å 为å¦æä½ å¨å²åºé¶æ®µæ¿æ
,äºå¤ªå¤,ä½ å°±ä¼æ³,å¦,好å§,æ们没æ¶é´åè¿äº。æ¹è¿äº,对å?å¼å°äºä¸ä¸ä¸ªå²åºè®¡å,æ们就ä¼æ³,å¦,ææä»¬æ ¹æ¬ä¸äºè§£æ们产å积åä¸çä»»ä½ä¸è¥¿。好å,æ们åå®èäº。好å,æ们åå¾ååæ ·çç。这å°±åä¸ä¸ªæ»å¾ªç¯。ä½ è¿ä¼åç°,é·å
¥è¿ç§å¢å°çå¢éå¾å¾æ æ³å®ç°ä»ä»¬çå²åºç®æ 。æ以ç°å¨ä»ä»¬ä¼å 为没æè¾¾å°å²åºç®æ èä¸å¼å¿,å 为è¿åºè¯¥æ¯ä¸ä»¶äº,对å?å æ¤,ä½ ççå¢éå¨æ¯ä¸ªå²åºé¶æ®µé½ä¸æ£éå¤æ æ³å®æè¦æ±ä»ä»¬å®æçççç。