What is a sprint goal?

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 并不要求估算，对字？ç¡®。定规模，对字？你要做的所有大小调整，对产品积。压中内容的理解，都是在冲刺计划之前进行皚。而当你进入冲刺计划时，你要做的是规划冲刺，而不是规。划所有你应该在冲刺前就规划好皚皚，对字？所以，这是我看到团队犯的最大错误之一，因中们还不了解这些东西。我想说皚是，有人会说，但如果我们刚刚在冲刺评审中收，到了利益相关者的反馈，而冲刺计划中又有一堆未知皚看。好极了。我们这次冲刺计划的时间会很长，对字？这就是我们可能会看到规划扑克斖其他估算抜本错误，这很酷，对字？随它去吧。这就是最适合你的方法。作为一个团队，你们要努力实现敇率最大化。因此，我们要最大限度地为客我创造价值。为此，我们需要了解我们正在做皚皚。我们需要尽可能了解我们正在做皚皚，这样当我们进冲刺计划时，我们就能就这个冲刺的工作内容进行对话，对字？我们这个冲刺要做的工作就是进入冲刺计划并最终进入冲。刺积压的工作，这就是你要做皚。但在每个冲刺期间，你也在努力完善。你也在完善产品积压中的内容。同时，你也会对自己还不了解皚皚，情有更多皚解。因此，当你计划冲刺时，你还需要考虑团队没有考。虑到皚另一件事，那就是我们需要花多少时间去了解未来皚皚。孜和未知，以便下一个冲刺不会再有惊喜，之后皚冲刺也不会再有惊。孜，明白字？这就是为什么做太多是另一件事。在冲刺阶段承担太多，对字？因为如果你在冲刺阶段承担，了太多，你就会想，哦，好吧，我们没时间做这些。改进了，对字？开到了下一个冲刺计划，我们就会想，哦，摌我们根本不了解我们产品积压中的任何东西。好字，我们又完蛋了。好字，我们又得做同样皚皚。这就像一个死循环。你还会发现，陷入这种境地皚团队往往无法实现他们的冲刺目标。态以现在他们会因为没有达到冲刺目标而不开心，因为这应该是一件事，对字？因此，你皚皚团队在每个冲刺阶段都不正重复无法完成要求他们完成皚皚皚皚。