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

  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
  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
  4. My experience Based on Ukrainian Outsourcing companies in 2015-2017 4

  5. 5

  6. 6

  7. 7 Quality is bad all the time

  8. 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?
  9. 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?
  10. 10 Non-functional Requirements are missed

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

  12. What is Quality? 12 Attributes: ▰ Portability ▰ Reliability ▰

    Efficiency ▰ Usability ▰ Testability ▰ Understandability ▰ Modifiability
  13. 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
  14. 14 User Stories from PO are Functional Requirements only

  15. 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!
  16. When you don’t need technical backlog? Now don’t you? 16

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

    always scapegoats“
  18. 18

  19. 19

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

  21. User stories 21 As <persons> I want to <goal> So

    that <value>
  22. 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.
  23. 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.
  24. 24

  25. Product backlog 25 ▰ Consist of users stories: As a

    <persona> I want <goal> So that <reason> ▰ Functional requirements ▰ Demo for PO and stakeholders ▰ Delivery as working software
  26. Technical backlog 26 ▰ Consist of technical stories ▰ Non-functional

    requirements ▰ Demo for development team ▰ Delivery as artifact (package, document, etc)
  27. 27 Developers are Tech Backlog Stakeholders

  28. Technical stories? Several new definitions 28

  29. 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
  30. 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
  31. 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
  32. Technical Backlog Sources New scrum ceremonies 32

  33. 33 Input from Development team

  34. 34 Grooming

  35. 35 Postmortems or Production Incidents Research

  36. 36 Architecture board review

  37. 37 Domain Design Review

  38. How to ‘sell’ work from technical backlog? the simplest is

    always the most difficult 38
  39. 39 Identify/highlight problem

  40. 40 Assessing the consequences of not solving the problem

  41. 41 Make sure that decision makers aware that this is

    a problem and know the assessment
  42. 42 Generate solution(-s) and estimate(-s)

  43. 43 Get a confirmation

  44. 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
  45. 45 Don’t sell a problem, Sell the solution

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

  47. 47 Doing things the quick and dirty way sets us

    up with a technical debt which is similar to a financial
  48. Reason of technical debt 48 ▰ Prudent decision, because “Deadline

    is coming” ▰ Reckless decision ▰ Unaccounted non-functional requirements ▰ Technical Inflation
  49. 49

  50. 50 Not everything in the technical backlog is a technical

    debt and vice versa.
  51. 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