Baixe o Infográfico Scrum by Scrumhalf agora e disponha de um resumo completo do Scrum para ajudar a sua equipe.
Suddenly you found yourself with a remote team, without really planning or preparing for it. Keep Cool. A study from the American Census published on Computerworld indicates that from 2005 to 2017 remote work increased by almost 160%. The new reality of work may be strange, but in addition to the fact that many companies have adopted remote work for a long time, we have already gained some experience to point out good practices for remote work, or home office.
Usually some concerns are highlighted: How will we manage to coordinate the work with the team distributed? How will we be able to work without the same social interaction that we had in the common workplace? And what about the impact for people?
I recently came across an article that caught my attention. Here’s Why Many Developers Hate Scrum, or Why Many Devs Hate Scrum, makes an analysis of the work in Scrum, indicating, mainly, an increase in load for developers, due to the needs created by the use of the Scrum framework. As interesting as I found the article, and it really is interesting, I noticed several points of disagreement, or that deserved an explanation, which ended up leading me to also make a similar analysis. There is no intention to negatively criticize its author, nor his opinion, not least because it was thanks to it that I developed this, let’s say, complementary analysis. I believe that another look at the problem presented can help Devs who are experiencing this dilemma.
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