Category: Agile Planning

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.

User stories in Scrum are work items that the team implements and turns into working software. The product owner is mainly responsible for developing user stories. However the team will have to work with the product owner to refine the user stories to ready user stories. This means the stories must be clear, concise, and immediately actionable. I’ve personally seen many teams struggling through the sprint, holding endless debates and get nothing done by the end of the sprint. The reason was simple that the user stories were not actionable and the result was frustration amongst team member as well as product owners.