O Burndown Chart, ou gráfico de Burndown, é um dos recursos que o Scrum nos oferece para vermos o andamento dos trabalhos em uma Sprint. A principal função do Burndown deve ser apontar discrepâncias entre o combinado e o realizado, no sentido de permitir a devida intervenção. Quando falamos intervenção estamos querendo falar sobre a análise do time do cenário em que se encontra, para identificar possíveis problemas e efetuar correções, sempre que possível.
É evidente que nem todo atraso na realização de tarefas, ou falhas de entrega do time ao final da Sprint, pode ser remediado. Entretanto,
We already understand what a story is in Scrum and how to work stories using INVEST. Let’s now take a look at how to classify these stories.
As we have seen, stories are the requirements of the project / product being worked on. Stories are kept in Product Backlog and sorted by work priority. So it is natural to have several stories to work on our Backlog.
Considering that products are created or developed in collaboration with the entire team, as well as external agents such as stakeholders, product managers, etc., everyone should be encouraged to make their contributions as stories. However, only the
When we design a new product, or when we think of a problem to be solved, we are faced with different levels of knowledge about the various aspects to be addressed. Certainly, some characteristics that we wish for the product we know well and we manage to detail. Other, we have only one idea, a high-level vision of what we want. Also, it does not make much sense to define a product with a huge amount of stories, or Backlog Items (PBI – Product Backlog Item). It gets confusing and hard to explain to anyone. So it is only natural that
User Stories – are a matter of doubt for many beginners, and sometimes even for practitioners with some experience. This is even proven by the statistics of our Blog (with more than 10 thousand readers / month), which shows that posts about User Stories are always among the most wanted. So, let’s try to see Stories in a practical and simple way. This series of posts is dedicated to this.
A Scrum project has its requirements organized into a list called Product Backlog. Thus, roughly, the requirements of a project or product are items in this list, or rather Backlog items. The most commonly used way to describe
In recent times has gained a new movement called #noestimates? What does that mean? What is the advantage of adopting this path? The movement, if we may call it, #noestimates is based on the statement that “estimates do not generate value”. Based on this, he preaches that we must avoid estimating, reducing such activity or even extinguishing it. He advocates that we should devise alternatives to estimation. Will be? Is this path for us? Let’s start by talking a bit about