Shaping our development process


Why are we here?


-------------------------------------------------

What

do we want to improve?

-------------------------------------------------

How

are we going to improve?

-------------------------------------------------

Scrum process


The way we did things


- PO identifies functionalities & features

- PO (& RA) create(s) user stories

- PO (& RA) discuss this with IxD

- IxD makes design proposal

- User stories are completed with details

- PO prioritizes stories

POKER SESSION

- User stories are presented to team for estimation

- Scope of sprint is determined by estimated points

START OF SPRINT

Pain points business


- Lack of vision & decisiveness

- Lack of knowledge about actual users & usage

- No case (holistic view/concept) to present to dev. team

- Too little overview

- Product backlog is not complete or organized

- PO must specify technical details (fuzzy stories)

- Too many stories

- Too much time spent on documenting & specifying stories

- Too little time spent on actual backlog grooming & prioritization

Main issues with this approach


- dev team is involved too late within this process

- dev team is not a part of how the stories come about

- dev team is not adequately involved in thinking of solutions

- PO struggles with stories

Pain points dev. team


- Exchange between UX and developers can be improved

- Developers aren't sufficiently involved in thinking of solutions

- General lack of understanding of the users

- Stories/epics are in illogical order from dev. team's perspective

- Dev. team has (too?) little input

- Concept of 'Def of done' is too fuzzy & rigid
(difficult to squeeze it into a sprint)  

Result


Development team is NOT empowered to:


  • be creative, think of solutions
  • create tasks 
  • break-down stories
  • prioritize stories within sprint
  • own the stories within the sprint
 

What to improve?


Exchange ideas across team members


Pro-activity in coming up with solutions


Decisions regarding technical solutions and UI lie with the dev. team


Owning our dev. process


Test early, involve users


Proposed

Solution

Before we get started


  • Business case √
  • Concept √
  • Vision √
  • Initial product backlog (epics) √
  • Release plan √


To get this done PO needs a Project Manager, Architect, UX designer and Requirements Analist.


With this the development team gets the neccessary introduction

from Product Owner & Project Manager

    ...And



    Know your user!

    Ok great. How do we get there?

    PO provides:


    Who's our customer?


    What pain points do they have related to our product?


    How will our product solve their pain points?


    What features are important?

    UX for proper preparation


    UX investigates customer problems & gathers info
    (works with PO/RA)

    Interviews might follow (users)

    Reporting might follow

    UX design peaks





    Proposed scrum process


    1. Workshop (pre-poker session) lead by UX
      - prepare

    2. Sprint planning meeting
      - estimate & plan

    3. START SPRINT
      - go go go

    Seperate the


    WHAT 


    from the


    HOW


    PO provides WHAT, we provide HOW

    (and don't forget to ask yourself WHY)

    UX workshop

    1. UX workshop

    Brainstorm session *Input from the epics*


    • UX explains user & his problem

    • Present possible solution/sketch to get started

    • Each team member thinks of possible solution (sketch)

    • Every one gets few minutes to present his solution

    • Come to best solution by choosing/merging ideas

      Result


      BAMMM!!!

      Solid stories!



      2. Sprint planning meeting


      • Stories are selected by the team from the top of the product backlog
      • Keep in mind the velocity of previous sprints
      • Break down stories (if needed) into tasks of 4 - 16 hours of work
      • Ask PO questions if neccessary
      • Think about acceptance tests (criteria)
      • Estimate stories


      NOTE:
      Additional functionality can only be added to the sprint by the development team!

      3. Start sprint


      • 2 week sprints

      • Developers pick up stories based on expertise and priority

      • Acceptance test preparation?

      • Stories move from
        to do - in progress - review - test - demo - done

      Definition of done


      Definition of done


      Stories might deliver:

      • 'finished' functionality, incl. design
      • all functionality, no design

      • a (HTML) prototype
      • javascript/html prototype


      The end product at the end of the sprint may vary, depending on the story. This is neccesary since a sprint only has a fixed amount of time.

      You cannot always squeeze the entire life cycle of creating a feature or functionality into ONE sprint. These are EPICS!


      Dod: Team's agreement

      Testing

      Testing


      Test as the final stage of a story before moving into done, can be user testing or some other form of test depending on the story. Therefore gathering valuable user feedback before finalizing a component or EPIC (in a future sprint).

      This fits well in the Scrum methodology of continues improvement.

      Epics & Definition of done


      For epics there can be different criteria than for stories.


      For example, performance testing can be part of delivering an epic, documentation, refactoring (decreasing technical debt) etc.

      The end

      Made with Slides.com