Archiv der Kategorie: Uncategorized

Magic Estimation Quickstart – Kurzanleitung:

Veröffentlicht am von
Antworten

What is ‘Magic Estimation’ about? (Source: https://www.scrum.nl/blog/magic-estimation/)

It’s an exercise for the Scrum team to estimate an entire product backlog with story points in a reasonable short amount of time. It’s a useful format to get some insights of the size of a backlog. Is it one month, 3 months or 6 months of work we’re talking about?

What is the source?
I don’t know of whom the original idea came from, but there are already quite some blog posts that describe the format, for example:
Core dump – rapidly estimating huge backlogs
Campey blog – magic estimation
Mike Pearce blog – how do I estimate how long an Agile project will take?

Duration
30 – 60 minutes in total, approximately 5 minutes per estimation round.

How I’ve used it
I use it at the start of every new project to estimate the size of an entire product backlog, which gives the opportunity to create a product roadmap. Sometimes I also use it during a project, when for example a new large component needs sizing. Having a quick estimate about the effort, might give the Product Owner enough insights of the return on investment.

What you need
Sheets with the estimation numbers (0, 1, 2, 3, 5, 13…)
Markers and pens
Product Backlog Items (PBI’s) written on small cards

How to do this
Preparation:

  • Spread the planning poker cards next to each other on the ground with the question mark at the end;
  • The Product Owner shares the vision of the product and briefly explains the contents of the product backlog;
  • The Development Team selects the PBI that will be used as the baseline. For example PBI X will be set as the five pointer, all the other PBI’s should be related to this story. It’s crucial
  • everyone fully understand this PBI;
  • With teams new to using story points, the Scrum Master should also explain what should be taken into account when estimating with story points. A story point is a combination of complexity, repetition and risk;
  • The cards, on which the PBI’s have been written, are divided among the group. Every team member has a unique set of PBI’s.The estimation process:
  • If there are no further questions, round one starts and everyone studies his/her PBI cards and puts them by the amount of story points they think suits the necessary effort best. This is done in silence, no discussions are allowed;
  • If someone doesn’t know what is meant with a PBI, it is placed at the question mark;
    When all PBI’s have been estimated, the number is written on the PBI card;
  • The PBI’s placed at the question mark are clarified by the Product Owner and discussed within the group until the intention is clear. After this they are divided amongst the group and placed at the amount of story points they think is most suitable;
  • In round two, which is again done in silence, everyone can check all the cards that are now on the ground at a Fibonacci number. When someone thinks a PBI should get another estimate, he simple picks it up and replaces it. This round continues when everyone has checked all the PBI’s;
  • The PBI’s that haven’t been changed are probably clear to everyone and are handed over to the Product Owner;
  • The PBI’s that changed slightly (e.g. from 2 till 3 story points) are also given to the Product Owner. Remember, the intention is to estimate an entire backlog, these minor changes aren’t relevant at this level;
  • In the same round, PBI’s can only be changed once. You can do as many rounds as you want, just remember to write the story point number at the cards after every round. I often use three rounds in total;
    PBI’s that have been changed a lot are discussed centrally until there is consensus on the amount of story points;
  • The exercise is finished when all the PBI’s are placed at a story point number and everyone agrees with the final result.The result
  • The Product Owner now has a set of PBI cards on which an estimate is written. This might be a single estimate when it hasn’t changed, or multiple estimates when it did;
  • Even when there is consensus on all the PBI’s, I always advice to keep the lowest and highest estimates of the PBI’s so it can be used for worst and best case scenario’s.
  • The entire Product Backlog now has been estimated in story points and based on the velocity of the team; the necessary amount of sprints can be calculated. This is of course a rough estimate, but it gives you an indication of the size of the Product Backlog.

    Frequently asked questions
  • What if I don’t want to use story points but t-shirt sizes? No problem, the exercise doesn’t change much. Just select a t-shirt size as the baseline and start the game!
  • What if I don’t know my team’s velocity, what is the value of the total amount of story points? Of course you will know the real velocity after the team has finished 3 – 5 sprints. But you can ask the team to select different sets of PBI’s they think can be finished in one sprint. When doing this, hide the amount of story points to encourage using their gut feeling. Of course this really is a rough estimate but it can help to create the first version of a roadmap.
  • Can I also use magic estimation during the sprint planning? No, Magic Estimation should be used as an activity during a refinement session.Success factors
  • It helps when the Development Team is experienced with story points and planning poker;
  • Use a clear PBI that everyone understands as the standard/baseline;
  • The development team should already know the intention & vision of the product and understand most of the PBI’s. This prevents ambiguity and increases the chance of a successful session.I hope this blog post inspires you to give this exercise a try yourself. If so, I would really like to hear your experiences!

Von der Idee zum Produkt. Ein Playbook für professionelle Produktentwicklung mit agilen Methoden.

Veröffentlicht am von
Antworten
  1. Domäne verstehen (fachlich und technisch) mit Event Storming
    1. Analytics Pfad:
      1. Erste Use Cases mit User Story Map erfassen und den Scrum Backlog anlegen
      2. Daten Analyse Plattform MVP inkrementell mit Scrum entwickeln
      3. Analytics Use Cases weiter entwickeln
      4. Business Ideen für neue (digitale) Produkte oder Produkterweiterungen ableiten
    2. Replatforming Pfad:
      1. Mit Domain Driven Design Subdomänen-Ziele definieren um den Big Ball of Mud inkrementell abzulösen
      2. MVP der ersten Subdomäne mit Scrum entwickeln und damit Teilfunktionen des Altsystems ersetzen
      3. Den MVP erweitern bis alle notwendige Funktionalität einer Subdomäne enthalten ist
      4. Parallel weitere Subdomänen mit Scrum vom MVP zur Vollständigkeit entwickeln, solange bis Altsystem vollständig ersetzt ist
      5. Neue digitale Business Ideen auf dem Neusystem mit Scrum entwickeln (teilweise parallel)
  2. (digitale) Business Ideen testen
    1. UX Prototyp mit Design Sprint Prozess testen
    2. Für die positiv validierte Business Idee einen UX und Style-Guide vorbereiten
  3. Neue digitale Produkte inkrementell zum Produkt-Market-fit entwickeln
    1. Für den MVP der validierten Business Idee eine User Story Map und den Scrum Backlog anlegen
    2. MVP mit Scrum entwickeln
    3. Produkt KPIs qualitativ und quantitativ auswerten und Produkt inkrementell mit Scrum zum optimalen Product-Market-fit weiterentwickeln

Agiles Prinzip Nummer Drei und Scrum + DevOps

Veröffentlicht am von
Antworten

das beinhaltet, schafft den Rahmen der es dir erlaubt funktionierende regelmäßig innerhalb weniger Wochen den Endkunden zur Verfügung zu stellen. Das heißt und gehen einher mit Prinzip Drei hinter

DOI – Scrum.org Partnership