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

Technical backlog usage instructions at Kyiv Project Management Day 2017

Technical backlog usage instructions at Kyiv Project Management Day 2017

Nikita Galkin

October 28, 2017
Tweet

More Decks by Nikita Galkin

Other Decks in Programming

Transcript

  1. Technical backlog usage instructions by Nikita Galkin Oct 28, 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. 3 Manage Expectation

  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

  15. 15 User Stories from PO has Functional Requirements only

  16. How store Non-functional requirements? 16 ▰ 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 backlog AKA Technical backlog – this is our approach!
  17. When you don’t need technical backlog? Now don’t you? 17

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

    always scapegoats“
  19. 19

  20. 20 Startup

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

  22. 22 Time to Market VS Quality

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

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

    is coming” ▰ Reckless decision ▰ Unaccounted non-functional requirements ▰ Technical Inflation
  25. 25 Not everything in the technical backlog is a technical

    debt and vice versa.
  26. Types of debt in software development 26 ▰ Tech debt

    ▰ Process debt ▰ Team (HR) debt ▰ Infrastructure debt ▰ Product debt ▰ <Your type> debt
  27. What is technical backlog? Let’s manage expectations 27

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

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

    requirements ▰ Demo for development team ▰ Delivery as artifact (package, document, etc)
  30. User story 30 ▰ 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.
  31. Tech story 31 ▰ 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.
  32. Technical stories? Several new definitions 32

  33. Types of Technical Stories 33 ▰ Product Infrastructure. For example,

    new microservice or Database. ▰ Team Infrastructure. For example, new feature for CI ▰ Refactoring. Changes in codebase for improving maintainability. ▰ Bug fixing. ▰ Spike. When it’s time for R&D adventure
  34. Our approach 34 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
  35. Our approach 35 Tech stack: ▰ Saved in confluence ▰

    Declare approaches and philosophy ▰ Describes tools/libs with purpose and version ▰ Contains change log with date and issue
  36. Technical Backlog Sources New scrum ceremonies 36

  37. 37 Input from Development team

  38. 38 Grooming

  39. 39 Postmortems or Production Incidents Research

  40. 40 Architecture board review

  41. 41 Domain Design Review

  42. How to ‘sell’ technical backlog? the simplest is always the

    most difficult 42
  43. Selling algorithm 43 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
  44. 44 THANKS! BE AWESOME! MANAGE EXPECTATION! You can find me

    on Twitter as @galk_in Slides are available at speakerdeck.com/galkin or at my site galk.in