Technical backlog usage instructions at PM FWdays 2017

Transcript

1. Nikita Galkin GlobalLogic Technical backlog usage instructions
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 Last Talks: ▰ Docker for Node.js developer ▰ 5 production Node.js stories ▰ Testing in Node.js World ▰ TypeScript for Node.js applications ▰ Spec driven development in Microservices Links: Site GitHub Twitter Facebook 2
3. My experience Based on Ukrainian Outsourcing companies in 2015-2017 3
6. 6 Quality is bad all the time
7. Project is alive. Scrum is failed. Why? 7 ▰ Bad Product Owner and/or DoR? ▰ Bad Scrum Master and/or Ceremonies? ▰ Bad Team and/or DoD? ▰ Bad Backlog? ▰ All of that?
8. Project is alive. Scrum is failed. Why? 8 ▰ Product Owner and DoR ▰ Scrum Master and Ceremonies ▰ Team and DoD ▰ Backlog ▰ So what’s the issue?
9. 9 Non-functional Requirements are missed
10. Nonfunctional Requirements And how do we check them? 10
11. What is Quality? 11 Attributes: ▰ Portability ▰ Reliability ▰ Efficiency ▰ Usability ▰ Testability ▰ Understandability ▰ Modifiability
12. Who takes care of which attribute? 12 ▰ Portability – DevOps Engineer ▰ Reliability – Product Owner ▰ Efficiency – System Architect ▰ Usability – UX/UI Designer ▰ Testability – QA Engineer ▰ Understandability – Developer ▰ Modifiability – Developer
13. Which type requirements has every attribute? 13 ▰ Portability – DevOps Engineer – Non-functional Requirements ▰ Reliability – Product Owner – Functional Requirements ▰ Efficiency – System Architect – Non-functional Requirements ▰ Usability – UX/UI Designer – Non-functional Requirements ▰ Testability – QA Engineer – Non-functional Requirements ▰ Understandability – Developer – Non-functional Requirements ▰ Modifiability – Developer – Non-functional Requirements
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 backlog AKA Technical backlog – this is our approach!
16. When you don’t need technical backlog? Now don’t you? 16
17. How store Non-functional requirements? 17 ▰ Your outsource company has business model where “Developers are always scapegoats“ ▰ You live in perfect world ▰ You work in a startup company ▰ There is Chuck Norris in your development team ▰ You hide real picture from customer
18. What is technical debt? Several words about lending 18
19. 19 Doing things the quick and dirty way sets us up with a technical debt which is similar to a financial
20. Reason of technical debt 20 ▰ Prudent decision, because “Deadline is coming” ▰ Reckless decision ▰ Unaccounted non-functional requirements ▰ Technical Inflation
21. 21 Not everything in the technical backlog is a technical debt and vice versa.
22. What is technical backlog? Let’s manage expectations 22
23. User story VS 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. ▰ 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.
24. Product backlog VS Technical backlog 24 ▰ Consist of technical stories ▰ Non-functional requirements ▰ Demo for development team ▰ Delivery as artifact (package, document, etc) ▰ Consist of users stories: As a <persona> I want <goal> So that <reason> ▰ Functional requirements ▰ Demo for PO and stakeholders ▰ Delivery as working software
25. Technical stories? Several new definitions 25
26. Types of Technical Stories 26 ▰ 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
27. Our approach 27 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
28. Technical Backlog Sources New scrum ceremonies 28
29. Technical backlog source 29 ▰ Postmortems or Production incidents research ▰ Architecture board review ▰ Grooming ▰ Input from Development team ▰ Domain Design Review
30. How to ‘sell’ technical backlog? the simplest is always the most difficult 30
31. Selling algorithm 31 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
32. Examples 32 ▰ Losing data during deploy ▰ Gap in domain ▰ Security issue ▰ Memory leak ▰ Review bugfix pull request
33. 33 THANKS! BE AWESOME! BE AGILE! You can find me on Twitter as @galk_in Slides are available at speakerdeck.com/galkin or at my site galk.in