Kyiv Project Management Day (28.10.2017) Нікіта Галкін “Technical backlog: інструкція до застосування”

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