Technical backlog usage instructions at Kyiv Project Management Day 2017

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
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
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“
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