Throughout my agile journey I’ve experienced and facilitated many retrospective meetings for agile teams but also for long running projects. Often I’ve experienced that teams and sometimes even facilitators are not familiar with common basic structure of activities that an agile retrospective meeting should follow in order to make the meeting go smoothly and to generate qualitative action items for improvement. From my experience it helps teams a lot to when retrospectives are created along this structure of activities. The structure is published in the book Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen, which I strongly recommend for anyone who is new to the subject.

As my last post was about how to write good User Stories, this post is about good structures for them. When developing products that require several team and stakeholders to collaborate, it is beneficial to have a common User Story structure so that everyone can focus on the product instead of struggling with information and requirements about it. With all the points below please remember that a User Story should be a place holder for conversations. So avoid adding all details and take away room for negotiation and conversation.

As a Product Owner I would like to know how to write good User Stories So that I can provide ideal input to teams for turning requirements into a product increment. What is an User Story? An User Story is a brief description of a certain functionality or desired feature from a user’s perspective. In an User Story these pieces of functionality or features must relate to business value. As mentioned User Stories are very brief descriptions and with that become a place holder for conversations between business people and developers When this conversations take place, knowledge is spread across all involved people and a shared understanding is the result. User Stories focus on value to be delivered to an user. …

User Stories Well Done Read more »

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 »