É 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 idea with planning in a general way is to allow us to prepare for the future, especially with regard to making decisions that promote the effectiveness and efficiency of our project. In this article Planning a Sprint: Velocity and Estimation, eg, we talk about Sprint planning.

However, in addition, we should also understand that the process of estimating involves the search for knowledge about what one wants to estimate. In development projects, be it software or any other product or service, this means discussing the subject with the client / user. Search and investigate similar products or services or competitors. Often even promote discussions with experts. And this search for knowledge brings as a side effect a better understanding of what one wants to estimate. The more we know the more we agree, as we discussed in this post Well written Stories, more accurate estimations.

So, we come to the first important aspect, addressed in a way by #noestimates. We should only estimate if this is necessary for something that brings us value. Whether it is to forecast costs, deadlines, plan capacity, define project scope, understand dependencies between requirements and / or improve understanding about something we should do.

On the other hand, we know that estimates are inherently inaccurate, especially if wrong time. The literature related to software projects makes this very clear, as presented by Robert Glass, Here summarized:

1. Most software estimates are made early in the life cycle when there is little understanding of the problem.
2. Most of estimates is made by management or by marketing, not by who will actually build the software.
3. Rarely estimates are redone.

Considering such observations, we can also deduce for which estimates should not be used.

1. Determine something accurately.
2. Set challenges.
3. Reward performance.
4. Cure lack of commitment.
5. Establish confidence.

We know that estimates are often misused and need to be addressed. But estimates are an indispensable part of a planning process which, as we have seen above, serves at least to organize efforts towards the attainment of some objective.

How then? We tell the client that it is impossible to plan because we can not or should not estimate anything? Do we plan in detail all that we are going to do?

Well, we must first understand that the Agile movement perceived this problem in traditional development processes and established some policies that help reduce the negative side effects of estimates. I highlight the most related, in my view, the estimates: “Respond to changes rather than following a plan.” This means, for example, that in planning something we understand that our knowledge of what is planned will change and that we will need to review our planning. Everything to do with what we discussed above.

In general, the #noestimates movement, or the recommendations of it, follows the same path of many others that have arisen in agility: it brings several interesting insights, but it can not be applied in any way absolute or in any case.

Many projects and organizations with which we have contact already, in a way, when using Scrum, work with #noestimates. For the most part, teams estimate stories using story points. However, most do not estimate tasks by simply setting a timebox for them. It is common for teams to break their stories into tasks by limiting the size of their tasks so that they can be accomplished in a day, at most by two.

In conclusion, #noestimates is very valid, but does not mean that it should or can not be applied indiscriminately. If you add value, estimate is accurate. The most important thing to remember is that estimating by estimating only disrupts the team.

How has your experience in Scrum projects been? Does your team estimate it or not? Do you see value in estimating?

The post Estimate ou #NoEstimates? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Todos os desenvolvedores de software possuem um mesmo objetivo: Entregar software com valor, rápido e com baixo custo. Esse é um objetivo aparentemente simples, mas que tira o sono da indústria e academia há décadas. Correndo atrás desse sonho está a área da Engenharia de Software, buscando oferecer ferramentas, práticas e estudos para que o desenvolvimento e manutenção dos produtos sejam mais eficientes. Mas já parou para pensar em quantas técnicas, padrões, frameworks etc. existem? Incontáveis soluções são oferecidas e devem ser adequadas a cada um dos casos. Independentemente das práticas utilizadas, uma pergunta tem que estar em mente o tempo todo: Como anda a engenharia de software do meu projeto? E, para responder essa pergunta, foi criado o SEMAT.

O SEMAT (Software Engineering Method and Theory) foi fundado em 2009 para ajudar a resolver diversos problemas que a indústria vem enfrentando. Seu primeiro passo foi fornecer uma fundação (chamada de Kernel) que irá suportar todo o pensamento de software daqui em diante, independentemente das práticas e ferramentas utilizadas. Com esse kernel, é possível entender se o processo, seja ele ágil, cascata ou qualquer outro, está atendendo as áreas consideradas pelo grupo como essenciais: Os chamados Alphas. Esses Alphas são divididos em temas e se relacionam entre si das mais variadas formas, como podemos ver na figura a seguir.

Mais informações sobre o modelo, os estados e os Alphas podem ser obtidas no guia de referência, mas farei uma breve descrição de cada um deles a seguir:

Cliente:

Área que se preocupa em saber se o time entende os stakeholders e a oportunidade que está sendo endereçada

• Oportunidade: As circunstâncias que fazem apropriado a criação ou alteração do sistema em questão.
• Stakeholders: As pessoas, grupos ou organizações que afetam ou são afetadas pelo sistema.

Solução:

Área que se preocupa  em saber se o time estabeleceu um entendimento conjunto dos requisitos e implementou um sistema capaz de atender os mesmos.

• Requisitos: As restrições que o sistema deve atender para endereçar a oportunidade e satisfazer os stakeholders
• Sistema de Software: O sistema como um todo, composto de software, hardware e dados

Endeavor (Traduzido livremente para esforço):

Área que se preocupa com o time, sua maneira de trabalhar e com o trabalho a ser feito.

• Trabalho: As atividades envolvendo esforço (mental ou físico) com objetivo de alcançar o objetivo
• Time: O grupo de pessoas engajado no desenvolvimento, suporte e gerência do projeto
• Maneira de Trabalhar: O conjunto de práticas selecionado que guiará o time e ajudará no trabalho

Cada um desses alphas possuem um estado a ser determinado pela equipe, utilizando a técnica denominada de Progress Poker. Esse método foi criado para ser rápido de ser executado e prover valiosa informação sobre o projeto de uma forma geral. O objetivo é que a equipe avalie cada Alpha, os estados que o mesmo possuem e entre em um consenso da situação atual naquele quesito.

É importante avaliar os itens que não foram atendidos porque são eles os pontos a serem atacados para a melhoria do processo.

Para verificar na prática essa técnica, utilizamos em um dos nossos projetos e obtivemos o seguinte resultado:

Como podemos ver, estamos bem posicionados em relação a Cliente (Oportunidade e Stakeholders) e Solução (Requisitos e Sistema de Software) mas pecando um pouco na área de Esforço (Time, Trabalho e Maneira de Trabalhar).

Sabemos que a causa dessa situação se deu pela entrada de diversos membros novos na equipe que ainda não haviam internalizado as práticas e atividades que a empresa executa. Esse foi o foco de maior trabalho para que o cenário identificado fosse revertido.

Em relação as outras duas áreas, é satisfatório perceber que bons resultados estão sendo obtidos e as práticas adotadas continuam sendo mantidas.

Faça você também a avaliação do seu projeto e deixe um comentário com a sua impressão!

The post (Português) SEMAT – Como Anda a Engenharia de Software do Seu Projeto? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

today I want to discuss some details about the moment we are planning the next Sprint, more precisely at the stage of the Scrum known as Sprint Planning Meeting.

In this post here I've talked about planning for Sprint and tried to answer the question "How many items my team is able to develop?". In it, I talk about the use of the team velocity as a measure to assist with this selection.

In today's post I want to show that this measure is continually changing, and so it is important to be watchful and updating the team's velocity each sprint.

We can notice that by checking the amount of points did it at the end of successive Sprints. That amount is always changing and thus also the speed. The reasons for this change can be many:

• Absence of any team member
• Holidays over the Sprint
• Underestimation / Overestimation of backlog items
• Urgent and unforeseen items entering Sprint
• Others

In the project I work, we use the Planning Poker to estimate the points of backlog items (more info on how to do this here, here and here), but we also take note the amount of time (in hours) each item took to complete. Thus we can take, for example, the items we point with 3 points, check the total hours consumed, then divide by the number of items and we will finally have a relationship of how long, on average, the team leads to finish a 3 points item.

In the following table we can see that there has recently been a change in the amount of hours we took to complete items of 3, 5 and 8 points. The latter two had a subtle change, but the item of 3 points happened to be completed in 75% of the previous time. We should not understand that this reduction in the time necessarily mean that the team has become more efficient, but we must face as a natural change, since the points are based on estimates.

Still analyzing the table, we can talk about points vs hours, which was discussed in this post right here.

Looking at the data in the table we realize that hours do not form a linear function. In other words, it takes 2h to finish the 1 point item, but it does not mean that the 2 point items should takes 4h and so on. It's not quite there, after all we are dealing with uncertainty and our points of estimation are fuzzy (more about fuzzy here).

And you, dear reader, have you been measuring the speed of your team? Doing like this or any other way? Feel invited to share with us some of your experience.

Till the next post!

The post Sprint Planning: Velocity and estimate appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The burnup chart provides information on the progress of the project as a whole and not just on a sprint as in the case of the burndown chart. It clearly shows at what point the staff is (Deliverables) and where it should arrive (Demands). As we can see in the figure below, the burnup graph is built on two axes: on the horizontal axis times the time factor and on the vertical axis we have the factor that represents the working amount. This amount of work can be represented in points, effort measures, hours, etc., according to what is used in the day to day work by the team.

The graph shows two lines:

• Blue: represents the amount of work delivered to the client. That is, it represents the total stories (or backlog item) delivered throughout the project.
• Red: represents the amount of work being requested by the customer. That is, it represents the total stories (or backlog item) created for the project.

The distance between these two lines represents, each day (or another unit of time used), the amount of work that remains to be delivered in order to achieve the project objective at that moment. 

With this brief summary about the burnup chart, we present 4 interesting reviews that can be made through it.

1. Scope X Deliveries

The most immediate analysis we can do about this chart is the comparison of how much the project scope has evolved with how much work has been delivered over time.

If the scope of the project starts to grow much more than the amount of work delivered, then we may have a problem! For the project is growing in demands, but the speed of deliveries of the team is not keeping pace with the growth of these demands.

Points of attention:

• Perhaps it is time to study a possible increase in the team in order to increase the speed of deliveries or a study on what may be impacting the speed of deliveries.
• Or a study on why the demands are growing so quickly.
• In addition, comparing the amount of work delivered with the amount of work to be done over time allows us to measure the distance between what we want and what is being served through the project.

2. Regularity of deliveries in front of the project objective

Another interesting analysis is about the regularity of deliveries from the project to the goal.

For this analysis we draw a line from the origin of the graph to the point that represents the total demand on the last day represented in the graph, according to the green line shown in the figure below. If the blue line is always near the green line, the project is more balanced.

In addition, with this line it is possible to evaluate if we are advanced or delayed with the deliveries. If the blue line is above the green line, we are early. If the blue line is below the green line we are late.

Of course, this idea of ​​delayed or advanced depends on the characteristics of the project, even because daily deliveries will hardly follow a regularity.

3. Classification of work amounts into categories

Another interesting analysis that can be done with the burnup chart is the separation of amounts (demanded and delivered) into categories.

For example, in a software project we can have the categories Bug, Technical Stories and New Features. So we would have a line of the amount demanded and an amount line delivered for each category. This information could be viewed in a single graph so that for the classification of the example we would have 6 rows in our burnup chart. Or we could separate in three graphs, one for each category with a row of the demanded amount and a row of the amount delivered in each. This analysis allows us to study not only how much is being delivered as a whole, but also the nature of what is being delivered.

We can analyze in which periods more bug fixes were delivered or in what period we released more new features, for example. Or maybe studying when more demands are coming for bug fixes … Is it after many new features deliveries? And before?

Finally, by separating the amounts of work represented in the graph into categories we can make a correlation between the deliveries and demands of the different categories and seek strategies in order to optimize deliveries in order to reach the project objective.

4. Analysis of the quality of deliveries

An analysis that I recently did in a project that I participate in, and that can even be seen as an analysis of the separation of the amounts of work into categories, is a study on the growth of the demands of bug fixes in front of the other demands of the project. That is, an analysis that helps us measure the quality of the work being delivered.

If the amount of bugs found starts to grow much more than the other demands or if the amount of bugs starts to grow more than the amount of work delivered, it can be a sign of problem, probably related to the quality of what is being delivered through from the project.

In addition, this situation shows that the work that the team is delivering is at the same time generating more work (correction of bugs) for the own team. Thus the distance between the blue and red lines of the burnup graph will be increasing, when in fact what is wanted is that these lines approach and at the end of the project cross. From these 4 analyzes we can extract important information about the the project in question, not only evaluating the total work delivered, but also the nature of the project being delivered. Other analyzes can also be done according to the characteristics of the project.

Therefore the burnup chart provides a powerful and yet flexible tool so that you can evaluate the progress of a project as a whole over time, allowing actions to be taken to achieve the goal of the project. Is that you? Do you use the burnup chart? How do you do your analysis? Share with us through the comments! Until the next post!

The post 4 Burnup Chart Analysis Tips appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.