Technical backlog for non-functional requirements at XP Days Ukraine

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