In the dynamic world of project management and software development, clarity is paramount. The Definition of Done (DoD) serves as a compass, guiding teams towards successful completion. Join me as we explore its significance and uncover the keys to project success.
Measuring and using velocity of an agile team can be helpful in forecasting output of the near future. You need a certain stability in your team and enough data points / iterations. However, there are also things that could go wrong using velocity. Therefore I want to shed some light on pitfalls using velocity in agile planning. Velocity is not a measure for productivity! Velocity is only an indicator of how much work was done in the past, not how much work will be done in the future. It’s like measuring your running speed with a stopwatch and then using this value to predict how fast you can run tomorrow or next week. We would be able to predict who will …
This question has been the primary thing of focus for most people who are new to Scrum. Yes, it seems daunting at first, but it is not a challenge to get the right answer.
Little’s law is a theorem in queueing theory by John Little. What it says is that long-term the average number (L) of customers in a stable system equals the long-term average effective arrival rate (λ) multiplied by the average time (W) that a customer spends in the system. As a mathematical formula it’s: L = λ W In simple words, there is a relationship between the average number of customers in a stable system, their arrival rate, and the average time in the system.
Most people involved in Agile Software Development are familiar with User Stories which, in it’s slimmest form, consist of a narrative and a small set of acceptance criteria. But what about Epics? What exactly is an epic and how does it distinguish from a user story, theme, initiate, spike or task? Let’s have a look what the purpose of an epic is and what it usually looks like in Agile Software Development.
