• • Do you really use Scrum?
  • How adherent are you to the framework?
  • Do your teams have a hard time dealing with Scrum concepts?

The answers to these questions determine how much this new version of the guide can influence what you and your team do. On the day of the release the authors, other officials and several experts made some lives about the new version. We participated in some of them to gather different views and opinions on the subject. We will talk about the main changes and at the end discuss a little what happened.

The New Guide

The guide itself has shrunk. It went from more than 20 pages to 16. In addition, it was launched with the purpose of democratizing Scrum, that is, the main line of its launch was its reduction and some adjustments that were made to allow the guide to be used by others. activities other than software development. In other words, the main idea of ​​reducing the size, which also manifested itself in other aspects, is to make the guide less prescriptive, focusing more on its agile essence. A clear example of this is the case of the Daily Meeting. In its new version, the 3 basic questions of this meeting disappear – what I did yesterday, what I will do today and obstacles encountered – to focus on its essence as a meeting of micro-planning of activities.

Likewise, the authors believe that the changes now introduced make the guide more comprehensive, in the sense of contemplating areas other than IT, since Scrum is now widely used in activities other than software development.

The following changes made are noteworthy.

Team

We now have only one team: the Scrum Team. Previously the Team was defined by a PO, an SM and the Dev Team (or team of developers). In its new version, the Dev Team gives way to “Devs” (developers). Thus, a Scrum Team was formed by PO, SM and Devs. Time now exists only one. An attempt to lower internal barriers and increase group commitment.

Roles and Accountabilities

Following the same tune, the Roles that were already defined by Responsibilities  now boil down to Accountabilities. In Portuguese, both terms would be defined as responsibilities. However, according to the authors, the term Role was removed because it was being used incorrectly as a position in many organizations. In a way it seems to me that flexibility was sought again. By removing the Roles and defining accountabilities for team members, there was also the possibility of having other accountabilities associated with Team members, in addition to those defined in the guide. However, the Team continues to be formed by a PO, an SM and Devs.

Product Goal

In order to avoid that the Team is simply a manufacturer of features, running Sprints with the objective of performing as much work as possible, eventually losing the perspective of real value for the customer, the guide now introduces the concept of Product Goal. The Product Goal serves to keep the team oriented to what the customer really wants – Focus.

At the same time, this also allows the creation of good Definitions of Completed – DOD (Definition of Done) – used to evaluate the product increment, since they must always be created with a view to achieving the Product Goal.

The guide now makes it clear that for each of the following artifacts there is an associated orientation: Product Backlog oriented towards the Product Goal; Sprint Backlog oriented towards Sprint’s Goal; and Increment oriented to the Definition of Completed. If you use Scrumhalf, there is already room for everything: Product Goal in the project description, Sprint Goal in the Sprint description, and DOD in your project settings.

Still on the same path, that of providing transparency and generating focus, the guide starts to include in the planning of a Sprint, in addition to the usual questions of what to do and how to do it, the need to show why why to do it. This demonstrates Scrum’s commitment to promoting the alignment of the entire Team in one direction.

Self-management

In its earlier versions the guide stated that the team, or the Devs, were self-organizing. This time, the guide starts to define the team as self-managed, in a way establishing that the team itself can define who will perform each of the tasks. It may pass only as a rewrite, but it may have other consequences. Let’s see how this change will impact, if any.

Our Impression

It is certainly commendable to reduce the size of the guide, as well as the intention to make it less prescriptive. The changes in general are simple and effective, even if in a way they are just a new guise for existing practices, as in the case of the change from self-organized to self-managed.

The big disappointment, however, was due to the scope of the guide, especially with regard to the language used. During its launch, we had the opportunity to ask, for example, “why did the guide insist on Devs, if that is an exaggerated IT term”. The answer came well below what was expected. The panelists claim that several Teams from different areas were consulted and that the professionals considered themselves Devs, that is, developers, because they develop some type of product or service. Honestly, it didn’t convince me. Agilists who work with non-software development teams always find it difficult to use different terms than what is defined in Scrum, in order to better adapt the framework to the reality of their areas. A real change in this direction would be very welcome.

Finally, considering the current market and the organization of work in Scrum itself, the effect of removing roles, replacing them with accountabilities only, will have little practical effect, in our opinion. However, at the end, this will at least provide a topic for heated debates, as we already can see on social networks. Just to have an idea, take a look at this definitions.

I hope that user feedback will influence an upcoming version of the guide, making it really more suitable for other professional areas.

Have you read the new guide? What do you think?

The post What Changed in Scrum? Scrum Guide 2020 – 5 Noteworthy Points appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

I think that some Devs really have the vision aligned with what was expressed by Willem-Jan Ageling, the author, in his article, and, therefore, I decided to debate a little more the topics listed by him. I understand that some people can really find in these topics reasons to “hate” Scrum, but I believe that another view on such reasons can turn this hate into love.

The analysis by Willem-Jan , focuses on new responsibilities faced by dev’s when working using Scrum. Better then, take a look at these “new” responsibilities, dissecting the problem to understand it better.

• At the Sprint Planning — Determining a Sprint Goal, in cooperation with the Product Owner. The Development Team needs to assess if they can meet the Sprint Goal as this drives the Sprint

Are there traditional, or non-agile, teams where the manager does not ask about deadlines, or what can be done until a certain delivery date? Honestly, I never saw that happen. Quite the opposite. I have always witnessed this questioning being asked repeatedly, even generating heated discussions, and stealing time, and often tranquility, from the team. This issue can never be abandoned, as there is no way that an organization, which establishes goals and objectives, works with KPI and OKR, does not have any idea of ​​when it will arrive where. In fact, I think that Scrum helps the team a lot in this sense, defining a specific moment for such discussion, in a way limiting it, and preventing it from stealing more time from the team.

• At the Sprint Planning — Creating a Sprint Backlog. This entails selecting the Product Backlog Items that help meeting the Sprint Goal and to create a plan to deliver them.

In reality, I understand that the Dev Team only helps the PO, or clarifies its doubts, so that it selects the stories to be contemplated. It is the responsibility of the PO to define a goal with the team and define what can be done to achieve that goal. Although the assessment is up to them, he is the utmost interested and the one who provides the guidance. Regarding the necessary plan, I believe that there are two aspects. The first is that this practice of planning what will be done in the short term is extremely productive. In general, it avoids hacking. Or do we not know devs who, upon hearing the first news about a customer need, already want to sit down and go out programming? This small planning, significantly helps to avoid the mole effect and promotes collaboration and coordination between team members, under the risk of not doing so, generating rework and having a lot of coordination difficulties. In other words, in my view, such a responsibility has always existed. Only, some people, or teams, forget their need and end up paying a high price later.

• During the Sprint — Ensuring the Product Backlog Items meet the Definition of “Done” and acceptance criteria.

Could the team work differently? This seems to me to be inherent to dev’s work. Otherwise, the dev forgot to be working to satisfy the needs of some client, to be a dilletante.

• During the Sprint — Making sure the Sprint Backlog always shows the current state of the progress on the Product Backlog Items and the plan for the Sprint.

This responsibility does not seem like extra work, but only a matter of discipline, attention to the framework and use of an appropriate tool. The daily meeting, already built in Scrum and that should not be abandoned, has as part of its scope the presentation of  did/will do/problems. This, in itself, allows for an update of the work situation. If, in addition, the team uses a monitoring tool, as Scrumhalf, where the tasks worked are updated by the dev himself and automatically generate information, such as the Burndown chart, transparency and visibility are guaranteed, without any extra effort.

• At the Daily Scrum — Daily assessing the progress towards the Sprint Goal. This includes updating the plan as reflected in the Sprint Backlog.

Really, the Daily Scrum is something that takes time from the team. However, this time, which must be very short, around 15 minutes or less, would be much longer if the project had a formal manager and the team members had to make their progress reports for him. Additionally, it is essential to remember that the Daily Meeting is what enables the team’s self-organization, reducing traditional friction with management, and increasing job satisfaction.

• At the Sprint Review — Discussing the Sprint Goal and how they managed to reach it.

This is really not a common thing outside of Scrum. However, in addition to the fact that this discussion should not take too long, it should be remembered that, among other reasons, this discussion promotes transparency and ends up avoiding, or replacing, the constant discussions and debates of the Dev team with management, when using non-agile management.

• At the Sprint Review — Showing what they created and answering questions.

I’ve never seen this left out either. Dev Team can’t just code and forget. Unless there are other members to demonstrate the implemented features, note any bugs, etc. The advantage in Scrum is that since it is done in an organized way, faster, and with the participation of the entire team, it allows everyone to stay up to date, reducing interruptions of work in subsequent tasks.

• At the Sprint Review — Taking part in the discussion of what to do next.

Although I have always promoted this type of discussion in the projects I participated in, especially in the ones I managed, before agility, I recognize that the Dev Team is often left out of it. However, as a result, it is normal for the team to waste a lot of time later, complaining and discussing why something is being done. That is, the process of thinking about what should, or should not, be done is effectively carried out. The big difference here is that he will be able to express his thoughts and listen to that of the other companions. And, it must be remembered, responsibility, like mostly in Scrum, is collective, of the Dev Team, not individual.

• At the Sprint Retrospective — Inspecting how the Sprint went and create an improvement plan.

This one is really different. Kaizen, or continuous improvement, is something Scrum takes very seriously. It takes a little time from the team, but it brings enormous benefits, including allowing more and more the dev’s to focus on their main activity over time, since the “process” itself is working well. It is up to the Scrum Master to make this ceremony productive and enjoyable. Its results, which in a non-agile way should also be reached by good management, will always be implemented in the same way, regardless of the management model. I mean by that, if something needs to be changed, revised, it will have to be. And someone will have to do the job.

• Creating and maintaining the Definition of Done.

Truth. Now the team must worry about that. But let’s see. The definition of done, at least in the developer’s mind, already exists. Otherwise, how would he finish working on something? The difference here is that now the team must create a shared definition, which is understood by everyone. And, in fact, what initially may seem heavy, after agreement avoids a series of conflicts, is easy to maintain, and can, for example, be seem as a by-product, when necessary, of the Retrospective.

• Learning, exploring, and embodying the Scrum Values of Courage, Commitment, Focus, Openness, and Respect.

This only occurs, or at least in a striking way, when transitioning from a non-agile method to Scrum. It is, at that moment of the transition, an important cultural change. But after some time working this way, it starts to flow in the vein of the agilists and it becomes no burden. After all, isn’t life more beautiful like that?

To summarize, we set up the table below. In this table, we represent each of the responsibilities, in the same order as the text, and we try to indicate the need for their adoption in any project, regardless of the management model used. On its side, we try to demonstrate the impact if it is neglected. In Scrum, we try to show the main form of Scrum in dealing with the responsibility and, finally, we indicating if a tool can significantly facilitate the work of the team, if it adheres to Scrum. This table is empirical, without scientific rigor, being only the result of what we observed throughout the projects that we participated, directly or indirectly. The only purpose of this table is to compile the data, from our perspective, related to such an extensive list, synthesizing it, albeit superficially, to allow for a global view on the part of the reader.

Well, we tried above to complement the analysis made by our colleague Willem, to who we thank, aiming to give the Devs, or any element of a Scrum team, another perspective on their “new” responsibilities. The use of additional elements in the team, to take care of certain aspects show here, or the redistribution of some activities, can undoubtedly help, relieving some work, as pointed out by Willem. Evidently, discounting the communicational aspect made clear by Fred Brooks, in his seminal book The Mythical Man-Month, more people usually help to lighten the burden.

In conclusion, I think the main point is that Scrum actually fixes and organizes a number of things that in reality are already done in other ways in non-Scrum activities, and when it adds something extra, it is because it really is necessary and brings great benefits to the team. Can you think outside of the box and see these aspects in a positive way too?

*This is a Google Translation of the original article

The post 11 Reasons Your Team Shall Love Scrum appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

É evidente que nem todo atraso na realização de tarefas, ou falhas de entrega do time ao final da Sprint, pode ser remediado. Entretanto, esses problemas nunca devem passar despercebidos e o Burndown é um grande auxílio nesse aspecto, sinalizando que algo pode não estar indo como previsto. Ele serve como uma alerta, para que o time analise o quadro atual e o que será necessário fazer para entregar o combinado, ou até para adicionar novas atividades, entregando mais do que o combinado.

No entanto, infelizmente, muitas vezes esse gráfico tão simples e útil, é mal empregado e acaba trazendo prejuízos ao invés de benefícios para o time. Vamos dar uma olhada nos 3 principais vícios na utilização do gráfico de Burndown.

Controlar o Time

Não é vigiando o Burndown para avaliar o trabalho do time que as coisas vão mudar. Na verdade, esse tipo de atitude atrapalha muito o funcionamento da agilidade. Na agilidade todos trabalham com comprometimento absoluto. As pessoas são empoderadas para resolverem problemas e atuarem da melhor forma possível.  O controle indevido acaba se tornando um estopim para o início de uma crise na equipe. Acaba gerando contrariedade entre PO e time, com acusações mútuas que podem desencadear crises muito mais sérias. O gráfico de Burndown não deve ser utilizado com uma ferramenta para exercer o Comando e Controle.

Comparar Times

O Burndown também não é ferramenta para comparar times. Aliás, na Cultura Ágil, a preocupação deve ser muito maior em motivar do que comparar desempenho. O objetivo não é dar “pressão” no time, mas trabalhar junto com o time, buscando pontos de melhoria, para cada vez mais aumentar a eficácia e eficiência. O próprio sistema de pontuação de histórias, velocidade, e planning poker, utilizados na maioria dos times Scrum, não permite comparações entre equipes. É um sistema de pontuação sem uma referência única, onde cada time estabelece suas referências e seus valores de acordo com as suas percepções e capacidades, dentro de seus respectivos cenários. A utilização do Burndown para comparação de times além de inapropriada e sem nexo, é improdutiva.

Medir Performance

A performance do time de forma ampla é avaliada pelo cumprimento do combinado. Isso de uma forma geral acaba sendo feito conjuntamente durante a Retrospectiva, em função do resultado da Revisão. Acontece que, em alguns casos, membros do time, ou mesmo participantes externos, acham que podem utilizar o Burndown para avaliar o desempenho do time durante a Sprint. Ficar medindo performance através de indicadores como o Burndown, além de não ser adequado, cria um clima de desconfiança prejudicial, e acaba levando ao primeiro vício que citamos, o de tentar controlar o time, utilizando o modelo de Comando e Controle.

É importante que todos os envolvidos com o Scrum entendam que o Burndown é um mecanismos de transparência, de awareness, e não uma ferramenta de medição de desempenho para uso numa estrutura de Comando e Controle. O propósito do Burndown é dar visibilidade à evolução dos trabalhos, para permitir que o time faça a devida análise do mesmo, considerando o cenário e o momento que se encontram. Existem outras métricas bem interessantes que podem ajudar o time. Entretanto o Burndown deve, e precisa, ser usado de forma útil e frequente para ajudar o time a dar o seu melhor.

Como vocês estão usando o Burndown no seu time? O Burndown tem ajudado? Conta para a gente.

The post Burndown Chart – As 3 Principais Confusões appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The post Classifying User Stories – User Stories Revisited III appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

We often call these high-level epic items. They are stories that give an overview of the intended, but are still very large, in the sense that they require a lot of time for their accomplishment, and have few details, not having all the information necessary for the team to carry them out. A simple example of such a story would be The Director wants to control the stock to optimize the use of financial resources. This story is easy to understand when presenting the new product, however it will require much more than a Sprint to complete and does not have enough details to be implemented by the team.

Epics need to be detailed for the purpose of allowing the team to work. In general, there is no concern to work as in structured analysis, guarding the epic and successively blowing up its by-products. What we do in practice is to divide the epic into smaller stories that cover all that is desired in the epic, and can then discard it.

Then there is more than normal doubt: What level of detail is ideal? What granularity do we seek? To answer this we use an acronym proposed by William Wake, INVEST – Independent, Negotiable, Valuable, Estimable, Small and Testable. Let’s look briefly at each of these characteristics.

Independent

The ideal is that we can work on a story that is independent of the rest. So we can work on it at any time, without depending on others. This is not always possible, but it must be sought. That is, we try to minimize the dependences.

Negociável

A story must be able to be worked together by the client and the team. Thus, the concept must be well defined and the details are later resolved together. The essence must be captured, leaving the details as part of the implementation.

Valuable

A story has to provide value to the client. When dividing stories we should be concerned about maintaining the full vision of its implementation so that the client realizes its value and supports the development of the story. We have so-called “technical” stories where the customer often has difficulty in seeing value, but we’ll talk about it another time. Generally speaking, we must avoid them, trying to insert them as parts of other stories where the customer perceives value. This is not always possible.

Estimable

For the team can program their work and the client can prioritize the stories, they must be estimated. The larger the story, the more imprecise and difficult it is to estimate. Small stories should be small. They should be able to be done with few man-hours, a few days of work only. Additionally, small ones are estimated more easily and with greater precision.

Testables

Everything that is done by the team must be able to be verified and validated. A good exercise is to set the test before working on the story. If it is difficult to set tests, the story may not have been well understood or be at the wrong abstraction level.

It is fundamental for everyone in the Scrum team to understand that the work is done by stories and therefore the quality of the stories will define the effectiveness and the efficiency of the team. Still, the work in defining the stories, the necessary discussions and surveys, and other related activities, serve for the acquisition of knowledge by the team, and even by the client.

Returning to our simple initial example, we could replace our epic The Director wants to control the stock to optimize the use of financial resources by:

• Director wants to register the goods receipt to allow sales and limit the use of the warehouse
• Seller must register the goods issue to allow stock replacement
• Controller wants to check and adjust the quantity of existing merchandise to make the material balance

Smaller stories, which cover the initial need presented in the epic, and allow and guide the work of the team. With such stories, following INVEST, it will be easier to estimate.

On ScrumHalf  you can classify stories as Epics. Can you work your stories this way? What is your greatest difficulty? Tell us. Maybe we will not think of something together …

In the next posts of the series we will talk more about estimates, characteristics / types of stories, and other more advanced subjects. Keep following us. See you soon and good Scrum!

The post How to partition Epics? INVEST – Revisiting User Stories on Scrum II appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.