Er wordt ontzettend veel gezegd en geschreven over Scrum, maar hoe je in een Scrum omgeving met requirements omgaat, komt onvoldoende uit de verf.

Wij krijgen er althans voortdurend vragen over van analisten en product owners. Om daar voor eens en voor altijd antwoord op te geven, is Nicole een nieuw boek aan het schrijven.

Weet jij bijvoorbeeld waar Scrum in essentie om draait? In onderstaande afbeelding vind je het antwoord dat daarop in het boek Mastering Professional Scrum (aanrader) gegeven wordt.

Wij vinden het zo krachtig verwoord dat we het als quote hebben opgenomen in ons gratis e-book met 52 Agile requirements tips & inspirerende quotes. Mocht je het e-book nog niet hebben, download het dan hier. Gratis en voor niets!

Nieuw boek in wording

Het nieuwe boek gaat specifiek over requirements in Scrum. Het laat zien hoe je de echte requirements vindt en ‘how to deliver higher value more frequently’.

De kern van ons vak is immers niet veranderd, maar de manier waarop je te werk gaat des te meer. In het boek ontdek je welke principes, richtlijnen en tools Scrum je daarvoor aanreikt.

Na het lezen van het boek weet je hoe je:

  1. de focus vasthoudt op de requirements die er echt toe doen
  2. de ontwikkelaars niet te veel maar ook niet te weinig details geeft
  3. optimaal samenwerkt met het Scrum team en de stakeholders
  4. jezelf de agile denk- en werkwijze eigen maakt
  5. flexibel inspeelt op wijzigingen plus het overzicht behoudt
  6. met Scrum ook in een complexe omgeving het best mogelijke resultaat neerzet

Wat wil je nog meer weten?

Om zoveel mogelijk vragen die leven te beantwoorden en een boek te schrijven waar analisten echt op zitten te wachten, hebben we twee brandende vragen aan jou:

  • Wat mis je nog in bovenstaande lijst? Wat zou je in het boek willen lezen?
  • Welke van de 6 punten spreken je het meest aan? En welke het minst?

Wil je je antwoord hieronder in het reactieveld plaatsen? Dat helpt enorm om er een heel goed boek van te maken. Hartelijk dank alvast!

Nicole de Swart & Priya Soekhai

Misschien vind je dit ook interessant

12 reacties

  • Marcel

    Hoe je uiteindelijk met de requirements tot een echt product komt, in een agile omgeving. Dus o.a. de product visie en relatie met de requirements.

    • Nicole de Swart

      Oké Marcel, dit gaat zeker aan bod komen in het boek. Bedankt voor je reactie.

  • Walter

    Hoe houd je de software consistent wanneer er geen uitgewerkt design beschikbaar is? Tijdens refinement sessies kunnen teamleden zich uitleven in detailvragen en ideeën. Al naar gelang de discussie komt er dan een uitkomst. Op een ander moment zou de discussie tot een andere uitkomst kunnen leiden.

    • Nicole de Swart

      Dat is een hele goede vraag. Ga ik iets mee doen.

      • Rik Manhaeve

        Ik denk dat dit niet alleen een heel goede vraag is, het lijkt mij zelfs de hamvraag te zijn. Het voortraject voor we een product backlog opstellen, voor we met de lijst aan requirements beginnen, is essentieel. Doe dit niet zorgvuldig genoeg en de waarde zal blijven steken op een te laag niveau, of je het nu agile doet of niet.

        Dingen die in dit verband nuttig kunnen zijn: Disciplined Agile Delivery of DAD dat vooral de business kaart trekt en anderzijds dual track agile, spint 0 en dergelijke die de menselijke kant in de verf zetten. Als beide niet goed zijn afgedekt, wordt het een mislukking en de de aanpak (bv agile versus waterval) zal daar omzeggens niets aan veranderen.

  • Yvonne

    Ik sluit me aan bij de vorige vragen. Ik zie ook dat er een soort wildgroei aan oplossingen ontstaat omdat het team de oplossing die ze op dat moment het beste lijkt, kiezen (vaak zonder te kijken hoe een zelfde soort probleem in het verleden is opgelost). Je wilt in een organisatie die met standaardproducten werkt ook dat bepaalde acties in de software altijd op een zelfde manier worden uitgevoerd. En dan gaat het juist om de details. De ervaring lijkt me te leren dat ik requirements meer in detail moet uitwerken.
    Dus ik ben erg geïnteresseerd in punt 2 van de lijst!

    • Nicole de Swart

      Yvonne, werk je dan requirements meer in detail uit of ben je een oplossing aan het voorschrijven? Let op dat je niet op de stoel van de ontwikkelaars gaat zitten, maar blijf gefocust op de business.
      Als het team een wildgroei laat ontstaan en niet kijkt naar eerdere oplossingen, moeten ze daar vanuit IT (?) op aangesproken worden. Eventueel iets over opnemen in Definition of Done. Laat ze vooral zelf aangeven wat ze eventueel nodig hebben om hun verantwoordelijkheid op te pakken. Hopelijk heb je geen traditionele ontwikkelaars die alleen bouwen wat gespecificeerd staan in het agile team zitten.

  • Harry Friemann

    Weet niet of het wat brengt, maar gooi het toch hier in. Ik merk dat ik altijd een ketting van stories heb. Het start met een design voor een feature, dan moet de backend story de data leveren en dan de frontend story die het een en ander bij elkaar brengt. Als je geen dependencies wilt (disk) ben je dus voor elke feature zo 3 sprints nodig.

    Een ander punt is dat er zoveel gebeurt in het process, dat veel ideeen boven komen en die ik dan tot nog toe snel in een story gooi, in een apart “bakje” – die moeten ergens terug naar epics en langs de meetlat van productfeatures/moet het nu/wat levert het op – komen. Dat is een kunst op zich.

    Weet niet of ik voor je boek of topic ga, dan eenvoudig negeren. ben zoekende en erg nieuwsgierig naar jullie nwe boek

  • Ronald

    Mooi voornemen jullie boek. Ik zie ernaar uit.
    Hier mijn pennies.

      – Hoe om te gaan met externe partijen die nodig kunnen zijn in het definiëren en realiseren van requirements/stories, bv een IT servicedesk of ketentest partner.
      – Hoe je requirements op de juiste wijze formuleert.
      – Hoe je het empirisch houdt en voorkomt dat je toch gaat watervallen.
      – Hoe je als PO en “devs” in een scrum team met de klant requirements formuleert, zonder dat je de traditionele requirements- of businessanalysten beschikbaar hebt.
      – Hoe dat gebeurt in een refinement sessie (of niet).
      – Verschil tussen acceptatie criteria en definition of done.
      – Waarom je geen definition of ready zou willen in scrum.

    Succes!

    • Nicole de Swart

      Ontzettend bedankt Ronald. Hier kan ik wat mee.

  • Bert

    Mogelijke aanvullingen zijn:
    User stories zijn volgens mij niet compleet zonder acceptatie criteria. Of te wel hoe verrijk je user stories met adequate acceptatiecriteria? Of hoe pas je “Specification by example” en/of “Test driven design” toe in combinatie met user stories?

    Hoe beoordeel je user stories. Welke (automatische)hulpmiddelen staan er tot je beschikking voor het reviewen en beoordelen van user stories en user stories verzamelingen. Ik kom veel “checklists” tegen op internet, die je handmatig moet toepassen en dus veel tijd vergen, maar ook veel tools die de kwaliteit van user stories automatisch analyseren. Dit gaat verder dan verplichte velden invullen in backlog tools.

    Punt 2 is voor mij een belangrijk punt. En hoe ga je om met voortschrijdend inzicht en speel je flexibel om met wijzigingen in samenhang met punt 2.

Geef een reactie