Lean Agile Development 2.0


Reasons for this presentation


Learn from the past and improve the way we do things.

Have a solid development process in place which the team fully supports and owns and is adjusted to their needs.

A process which integrates UX and facilitates incremental development and early testing.

What we will discuss

Our process will consist of the following steps:


  • Preparation phase
  • Guesstimate
  • UX workshop
  • Sprint planning
  • Sprint!

Scrum process

Scrum roles


There are more roles than just PO, Scrum Master and Team members!

Role of Product Owner

  • Is market focused
  • Develops long-term and short-term product strategy & road map
  • Helps position the product against competition
  • Thinks about long-term viability of the product
  • Does NOT make "knee jerk"* decisions
  • Is responsible for the preparation phase and the product backlog






* an immediate unthinking emotional reaction produced by an event or statement to which the reacting person is highly sensitive

Preparation



There's more to it than just user stories & sprinting




Preparation is everything

Preparation phase


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


Must have in order to start the project!

MUST HAVE * MUST HAVE * MUST HAVE

    Who's prepping


    Product owner

    with help from
    Project Manager, Architect, UX Designer & Requirements Analist
    he puts this together.



    Role of Architect/Sr Developer

    in the preparation phase

    • Safe guard that other systems/applications, external partners and consumers of the application's data are not forgotten

    • Advise the PO in prioritizing the issues by assessing the possible technical solutions and effort required

    Vision

    Preparation leads to insight

    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?

    Know your user

    Personas

    Identify the user's pain points

    What is a pain point?


    • Something the user finds really annoying

    • Something the user can do but the path to doing it is extremely inefficient

    • Something the user repeatedly does incorrectly and then has to fix

    • Something it seems the user should be able to do but cannot (because of a bug or because there is no way to do it)

    Added value of prepping


    To ensure there is:

    a business case, solid vision, you know where you're heading

    and you know your user!


    And most importantly:

    to be able to communicate this to the development team to give them direction, a sense of purpose and so that they understand.


    This is the only way to reach a certain level of quality and create a foundation for writing stories.



    Output =

    Stories

    = WHAT

    Title

    Definition of Done for stories


    Stories have different acceptance criteria than tasks.


    For example, performance testing can be part of delivering a story, documentation, automated- or regression testing, refactoring (decreasing technical debt) etc.

    Before a story will be considered 'Done' all this criteria must be met. Some of this criteria can be separate tasks in a sprint.



    Stories


    Are specified by Product Owner

    with the assistance of the Requirements Analist

    and with the help of UX Designer (if the needs of the user have to be researched/assessed)


    "As an [user type] I want to [do some action]

    so that [business value]"


    Stories are not tasks!

    They're bigger and state WHAT needs to be built, not HOW.

    Stories (what) vs Tasks (how)


    Guesstimate stories


    Development team will 'guesstimate' (roughly estimate) the stories at the top of the backlog to give PO a rough idea and so that he can prioritize these.


    We can guesstimate based on T-shirt sizes!

      S | M | L | XL 

    Business value vs effort

    After the guesstimate PO is enabled to weigh value vs effort and base prioritization of the stories in the backlog on the relation between these two factors. Thus a guesstimate can help the PO in prioritizing the stories.

    UX workshop

    Pick up stories

    Role of UX Designer


    The UX designer(s) become facilitators and stewards of the design.


    Their goal is to communicate a vision for the product by building a shared understanding across the team. This shared understanding comes about through regular conversations and discussions around early design ideas.

    UX workshop


    • UX Designer 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

    • Team asks PO questions if necessary

    Sketch out idea

    Collaborate



    Output =

    Solution

    = HOW

    Break down into tasks


    Development team breaks down the story into tasks.

    Think of acceptance criteria when doing this!

    Keep with the Definition of Done (of stories).


    Sprint planning


    • Estimate the tasks in hours

    • Pull tasks into the sprint

    • Break them down further (if needed) into tasks of 2 - 16 hours


    Determining the goals of the sprint is a process of negotiation

    between the product owner and the team.





      Sprint!

      Sprint


      • 2 week sprints

      • Developers pick up tasks based on expertise and priority

      • Testers prepare acceptance tests

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


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

        Workflow


        Scrum master's role

        Team needs a dedicated Scrum Master

        Tasks & definition of done


        PO sets out DoD of stories - DoD of tasks are set by team


        Testing


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

        This fits well in the Scrum methodology of continues improvement.

        Deliverables of a sprint


        At the end of the sprint you might deliver:

        • 'finished' functionality, incl. design
        • all functionality, no design
        • a (HTML) prototype
        • JavaScript/html prototype


        Think in tasks!

        Deliverables of a sprint


        The end product at the end of the sprint may vary, depending on the tasks. This is necessary since a sprint only has a fixed (and short) amount of time.

        Remember: Scrum is a process, it doesn't dictate WHAT is done.



        You cannot always squeeze the entire life cycle of creating a feature or functionality into ONE sprint. Therefore don't expect to finish an entire story in one sprint, focus on completing tasks instead!

        Done

        Made with Slides.com