Při vývoji software se těžko odhaduje a těžko měří nějaká produktivita. Čím víc je práce předvidatelná, tím je věc lehčí. Čím víc se blíží výzkumu, tím je jakýkoliv odhad složitější.

Přesto je občas nutné zadat a trackovat do backlogu úkol, který je extrémně nejistý. Případně ani není jasné, k jakým krokům má dojít.

V tu chvíli přichází na řadu úkol typu research.

Úkol typu research je samostatný typ, měl by ho tedy ovládat i software, který na Scrum používáte.

O research platí, že:

  • zadání nemusí dodržovat strukturu User Story (kdo, co, proč)
  • je možné úkol ohodnotit body, ale s velkou mírou nejistoty
  • je určeno, jaký bude výstup (odpověď jde to/nejde to; odhad; analýza s popisem, jak daný úkol udělat)
  • je možný timebox, tedy určení, kolik času se smí úkolem nejvíc strávit

Potom, když takový úkol vkládáte do sprintu, očekáváte, že výstup vám umožní naplánovat, zanalyzovat, realizovat nějaký další úkol v dalším sprintu. To za předpokladu, že implementace může počkat do dalšího sprintu.

V okamžiku, kdy potřebujete daný úkol zrealizovat už v daném sprintu, ale je velmi nejistý, spojíte vlastnosti Research tasku s User Story.

Pak platí, že:

  • se dodržuje struktura User Story
  • dává se odhad v bodech
  • je určeno, že výstupem bude buď story, nebo odpověď, že se to nedá zrealizovat/stih­nout
  • je možné dát timebox, tedy určit, kolik času smí úkol nejdéle trvat, pak se musí jít za Product Ownerem a dohodnout se, jestli se má pokračovat (poznámka: mezi timeboxem a body by měla existovat relace, např. mnohabodový úkol těžko můžete timeboxovat na 1 hodinu)

Úkoly typu research se vyskytují přirozeně i v prostředí, kde součástí týmu je Business Analytik. Takové úkoly lze ale chápat spíš jako User Story a tak se i zadávají (je otázkou, zda dodržet daný formát, ale typ úkolu to bude US). Research úkoly jsou pro situace, kdy vám chybí netypická informace a cílem je informaci získat.