10 things to mess up your retrospective. It’s about time for a new list.
Today, I decided to write a list on how to mess up your retrospective. There are a lot of possibilities to do this and the following tips will help you doing so 1 – don’t prepare anything As the retrospective is the simplest and least important meeting of all Scrum meetings, it doesn’t need any preparation. Just come together and start. 2 – Start immediately As there is no need to set the stage, start immediately with gathering data. 3 – Don’t check if the tasks of the last Retro were done We don’t care about the old crap from the last retrospective. 4 – don’t use post its Post Its are evil!
5 – Forget about the Insight Insight? 6 – No DUE date Due dates are for waterfallers. 7 – no responsible Repeat after me: “We’re no waterfallers”. 8 – No time box This whole concept of a time box is exhausting, isn’t it? 9 – try to solve everything You collected a big list of issues? 10 – Always use the same scheme. More Notes on Story Splitting. In response to my recent Story Splitting post, I had a few questions and couple of confusions that need clearing up.
A few elements of the INVEST criteria need some discussion: Negotiable – the details are negotiated with the Product Owner as the team goes to implement the story. However that negotiation is a two street and not an excuse to ask for scope creep.Valuable – the story has to be valuable to a User however that may not be enough value to be worth releasing at this moment. Instead it may take several stories together to be sufficient value for the end user.
For example if we imagine the login page for a new site that needs to support its own signup system, Facebook, Twitter and OpenID. Should we Slice at all? The Product Owner has more opportunities to change direction. Finally I’m always being asked for more Story Splitting Examples. Original Epic: “As a first time user I want the to buy a book so that I can read it in my home” To start lets try splitting on Workflow: Agile Helpline!: Agile Planning - Backlog Management. Agile has not only reinforced the interest in project management, but also challenged the conventional ideas about such management.
It focuses on project management institutions where it is difficult to plan ahead with mechanisms for empirical process control, such as where feedback loops constitute the core element of product development compared to traditional command-and-control-oriented management. It represents a radically new approach for planning and managing requirements a.k.a. backlog management, bringing decision-making authority to the level of operation properties and certainties. The following video not only compares Agile backlog management with traditional backlog management, but also explains agile planning process in detail. Related Articles You can watch more agile educational videos at Agile TV.
Les spécifications Agile. Par Florent Lothon, Novembre 2012.
La documentation du projet est sans doute l’élément dont la durée de vie est la plus longue. Les technologies peuvent aller et venir dans le temps mais la documentation demeure l’héritage du projet. Pourtant nous échouons ou luttons souvent dans la maintenance de cette dernière. Les enjeux sont clairs : réaliser des spécifications compréhensibles à la fois par un utilisateur et par un développeur, à jour – donc fiables, donc faciles à maintenir – et non ambiguës afin de pouvoir vérifier objectivement la couverture du besoin. Cet article traite de différentes pratiques de spécification utilisées sur des projets Agile pour répondre à ces enjeux.
Partons du constat Les principes et pratiques abordés par cet article ont pour point de départ les constats suivants : Comparaison de l’efficacité des moyens de communication (Source : Alistair Cockburn) Un autre constat important concerne les limites de la communication par écrit (cf. schéma ci contre). Pratiques.