Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Technical backlog for non-functional requirements at XP Days Ukraine

Technical backlog for non-functional requirements at XP Days Ukraine

Nikita Galkin

November 11, 2017
Tweet

More Decks by Nikita Galkin

Other Decks in Programming

Transcript

  1. Technical backlog
    for non-functional
    requirements
    Nov 11, 2017

    View full-size slide

  2. Nikita
    Galkin
    Love and Know:
    ▰ how to make developers and business happy
    ▰ technical and process debt elimination
    Believe that:
    ▰ Any problem must be solved at the right level
    ▰ Software is easy. People are hard
    ▰ A problem should be highlighted, an idea should
    be "sold", a solution should be demonstrated
    Links:
    Site GitHub Twitter Facebook
    2

    View full-size slide

  3. ▰ Model: Team extension
    ▰ Project: port Windows Application
    functionality into Web
    ▰ Functionality: Monitoring & Management
    for QSC conference room servers
    ▰ Сhallenges:
    ▻ Node.js application in Firmware
    ▻ Cloud with 10000+ connections
    3

    View full-size slide

  4. My experience
    Based on Ukrainian
    Outsourcing companies in
    2015-2017
    4

    View full-size slide

  5. 7
    Quality is bad all the time

    View full-size slide

  6. Project is alive. Scrum is failed. Why?
    8
    ▰ Bad Product Owner and/or DoR?
    ▰ Bad Scrum Master and/or Ceremonies?
    ▰ Bad Team and/or DoD?
    ▰ Bad Backlog?
    ▰ All of that?

    View full-size slide

  7. Project is alive. Scrum is failed. Why?
    9
    ▰ Product Owner and DoR
    ▰ Scrum Master and Ceremonies
    ▰ Team and DoD
    ▰ Backlog
    ▰ So what’s the issue?

    View full-size slide

  8. 10
    Non-functional
    Requirements are missed

    View full-size slide

  9. Nonfunctional
    Requirements
    And how do we check
    them?
    11

    View full-size slide

  10. What is Quality?
    12
    Attributes:
    ▰ Portability
    ▰ Reliability
    ▰ Efficiency
    ▰ Usability
    ▰ Testability
    ▰ Understandability
    ▰ Modifiability

    View full-size slide

  11. Who takes care of which attribute?
    13
    ▰ Portability – DevOps Engineer
    ▰ Reliability – Product Owner
    ▰ Efficiency – System Architect
    ▰ Usability – UX/UI Designer
    ▰ Testability – QA Engineer
    ▰ Understandability – Developer
    ▰ Modifiability – Developer

    View full-size slide

  12. 14
    User Stories from PO are
    Functional Requirements
    only

    View full-size slide

  13. How store Non-functional requirements?
    15
    ▰ In DoD – DoD will be too big.
    ▰ In their own specification – nobody will read.
    ▰ In Acceptance Criteria for specific story –
    regression testing will be very difficult.
    ▰ In special part of backlog AKA Technical
    backlog – this is our approach!

    View full-size slide

  14. When you don’t need
    technical backlog?
    Now don’t you?
    16

    View full-size slide

  15. 17
    Your outsource company has business
    model where
    “Developers are always scapegoats“

    View full-size slide

  16. What is technical
    backlog?
    Let’s manage
    expectations
    20

    View full-size slide

  17. User stories
    21
    As
    I want to
    So that

    View full-size slide

  18. User story
    22
    ▰ Describes what the user does with the software
    and how the software responds. A User Story is a
    functional requirement that resembles a use case
    and test case.
    ▰ It contains the product owner expectations about
    customers needs.

    View full-size slide

  19. Tech story
    23
    ▰ A non-functional requirement that
    describes the functionality supporting
    the user-facing features in User Stories.
    ▰ It contains the team members
    expectations about project needs.

    View full-size slide

  20. Product backlog
    25
    ▰ Consist of users stories:
    As a
    I want
    So that
    ▰ Functional requirements
    ▰ Demo for PO and stakeholders
    ▰ Delivery as working software

    View full-size slide

  21. Technical backlog
    26
    ▰ Consist of technical stories
    ▰ Non-functional requirements
    ▰ Demo for development team
    ▰ Delivery as artifact (package, document,
    etc)

    View full-size slide

  22. 27
    Developers are Tech Backlog
    Stakeholders

    View full-size slide

  23. Technical stories?
    Several new definitions
    28

    View full-size slide

  24. Types of Technical Stories
    29
    ▰ Product Infrastructure.
    For example, new microservice or Database.
    ▰ Team Infrastructure.
    For example, new feature for CI
    ▰ Refactoring.
    Changes in codebase for better maintainability.
    ▰ Bug fixing.
    ▰ Spike. When it’s time for R&D adventure

    View full-size slide

  25. Our approach
    30
    Our JIRA types:
    ▰ Technical story with estimates, demo and the
    template “As ... I want to ... So that ...”
    ▰ Bug, without estimates and demo, but with
    template
    ▰ Task with free structure

    View full-size slide

  26. Our approach
    31
    Tech stack:
    ▰ Saved in confluence
    ▰ Declare approaches and philosophy
    ▰ Describes tools/libs with purpose and version
    ▰ Contains change log with date and issue

    View full-size slide

  27. Technical Backlog
    Sources
    New scrum ceremonies
    32

    View full-size slide

  28. 33
    Input from Development team

    View full-size slide

  29. 35
    Postmortems
    or Production Incidents Research

    View full-size slide

  30. 36
    Architecture board review

    View full-size slide

  31. 37
    Domain
    Design Review

    View full-size slide

  32. How to ‘sell’ work
    from technical
    backlog?
    the simplest is always the
    most difficult
    38

    View full-size slide

  33. 39
    Identify/highlight problem

    View full-size slide

  34. 40
    Assessing the
    consequences
    of not solving the
    problem

    View full-size slide

  35. 41
    Make sure that
    decision makers aware
    that this is a problem
    and know the
    assessment

    View full-size slide

  36. 42
    Generate solution(-s) and
    estimate(-s)

    View full-size slide

  37. 43
    Get a confirmation

    View full-size slide

  38. Selling algorithm
    44
    1. Identify/highlight problem
    2. Assessing the consequences of not solving
    the problem
    3. Make sure that decision makers aware that
    this is a problem and know the assessment
    4. Generate solution(-s) and estimate(-s)
    5. Get a confirmation

    View full-size slide

  39. 45
    Don’t sell a problem,
    Sell the solution

    View full-size slide

  40. What is technical
    debt?
    Several words about
    lending
    46

    View full-size slide

  41. 47
    Doing things the quick and dirty
    way sets us up with
    a technical debt
    which is similar to a financial

    View full-size slide

  42. Reason of technical debt
    48
    ▰ Prudent decision, because “Deadline is coming”
    ▰ Reckless decision
    ▰ Unaccounted non-functional requirements
    ▰ Technical Inflation

    View full-size slide

  43. 50
    Not everything in the technical
    backlog is a technical debt and
    vice versa.

    View full-size slide

  44. 51
    THANKS!
    MANAGE NON-FUNCTIONAL
    REQUIREMENTS!
    BE AWESOME!
    You can find me on Twitter as @galk_in
    Slides are available at speakerdeck.com/galkin
    or at my site galk.in

    View full-size slide