Category: Agile Planning

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.

After several posts around the topic of estimation and considering that estimations are often time consuming it is worth it to have a look at the alternative of not estimating at all. Therefore it is useful to become aware of why estimation is done or needed in first place. With that awareness you can asses whether these reason for estimating could be covered without the time invest for estimations. Reasons for estimations Planning right amount of work corresponding to a team’s capacity Decision making based on effort/cost versus value/benefit Prioritization based on estimated effort and uncertainty Cost calculation and budgeting of projects and initiatives Forecasting for customers and stakeholder management Release planning Get an idea on uncertainty or “readiness” of a …

#NoEstimates Read more »

Everyone who designs and manages products is familiar with the situation in which different ideas, requirements, market demands and legal regulations just pile up. You end up with a big stack of wishes and requirement and need to refine and prioritize them for implementation. Therefore a well maintained product backlog is highly beneficial and supports you in creating a good product. Here are practices that have proven useful to me over the years.