Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How do we keep track of things at Shutl

1,267 views

Published on

There are a lot of things that take place every day at a tech company like Shutl (an eBay company). How do we keep track of all those new features, bugs, etc? This presentation is part of our on-boarding materials.

Published in: Engineering
  • Be the first to comment

How do we keep track of things at Shutl

  1. 1. How do we keep track of things at Shutl (c) Shutl, March 2017 v1.0 Sergio Gutierrez-Santos
  2. 2. Note: this deck of slides is designed to be seen as a STEP-BY-STEP ANIMATION It is circulated as a PDF only for the sake of interoperability. If your PDF View Mode is “Continuous” and/or “Double Page”, we recommend that you disable those features now so you can see this animation slide-by-slide, one at a time. It will look weird otherwise. You have been warned. ;-) Enjoy! :-)
  3. 3. Legal stuff: You are free to (a) copy and redistribute this material in any medium or format, (b) adapt — remix, transform, and build upon the material for any purpose; but you are not free not-to reference the original source and authors. TLDR: this work is distributed under the terms of the Creative Commons Attribution licence (CC-by).
  4. 4. Moving on to the real stuff… :-)
  5. 5. When a company such as Shutl has a lot of developers producing code in parallel, it is difficult to keep track of all events that are taking place simultaneously, all the time, every day:
  6. 6. When a company such as Shutl has a lot of developers producing code in parallel, it is difficult to keep track of all events that are taking place simultaneously, all the time, every day: ● New features are added every week
  7. 7. When a company such as Shutl has a lot of developers producing code in parallel, it is difficult to keep track of all events that are taking place simultaneously, all the time, every day: ● New features are added every week ○ Sometimes they involve one developer, sometimes they involve a team ○ Sometimes they take a couple of days, sometimes a couple of weeks
  8. 8. When a company such as Shutl has a lot of developers producing code in parallel, it is difficult to keep track of all events that are taking place simultaneously, all the time, every day: ● New features are added every week ○ Sometimes they involve one developer, sometimes they involve a team ○ Sometimes they take a couple of days, sometimes a couple of weeks ● Bugs are found unexpectedly and need to be fixed
  9. 9. When a company such as Shutl has a lot of developers producing code in parallel, it is difficult to keep track of all events that are taking place simultaneously, all the time, every day: ● New features are added every week ○ Sometimes they involve one developer, sometimes they involve a team ○ Sometimes they take a couple of days, sometimes a couple of weeks ● Bugs are found unexpectedly and need to be fixed ○ Sometimes the cause and the solution is clear ○ Sometimes they require a lot of investigation (or ‘archaeology’)
  10. 10. When a company such as Shutl has a lot of developers producing code in parallel, it is difficult to keep track of all events that are taking place simultaneously, all the time, every day: ● New features are added every week ○ Sometimes they involve one developer, sometimes they involve a team ○ Sometimes they take a couple of days, sometimes a couple of weeks ● Bugs are found unexpectedly and need to be fixed ○ Sometimes the cause and the solution is clear ○ Sometimes they require a lot of investigation (or ‘archaeology’) ● Chores need to be taken care of all the time
  11. 11. When a company such as Shutl has a lot of developers producing code in parallel, it is difficult to keep track of all events that are taking place simultaneously, all the time, every day: ● New features are added every week ○ Sometimes they involve one developer, sometimes they involve a team ○ Sometimes they take a couple of days, sometimes a couple of weeks ● Bugs are found unexpectedly and need to be fixed ○ Sometimes the cause and the solution is clear ○ Sometimes they require a lot of investigation (or ‘archaeology’) ● Chores need to be taken care of all the time ○ Refactoring the code, managing users and beta-testers, helping customer support, etc
  12. 12. How we do keep track of all this complexity?
  13. 13. We use two tools...
  14. 14. We use two tools...
  15. 15. We use two tools...
  16. 16. We use Pivotal Tracker for high-level management of user stories, for prioritisation, and for planning.
  17. 17. It looks roughly like this...
  18. 18. It looks roughly like this... User stories are “stories with a value”
  19. 19. It looks roughly like this... Yellow user stories are in progress. Grey ones are waiting to start. Blue ones are in the Icebox for the future.
  20. 20. It looks roughly like this... User stories move up as they are completed
  21. 21. We use Trello for low-level tracking of progress of deliverables (usually code) and to find dependencies between teams.
  22. 22. It looks roughly like this...
  23. 23. It looks roughly like this... Tasks move right as they are completed
  24. 24. How do we do use them?
  25. 25. Let’s look at the whole process over time, from the beginning to the end
  26. 26. ○ A new user story (feature, bug-fix, chore) starts its life on Pivotal Tracker as a new “card”
  27. 27. ○ A new user story (feature, bug-fix, chore) starts its life on Pivotal Tracker as a new “card” ■ Usually product managers (PMs) do this (but developers can too)
  28. 28. ○ A new user story (feature, bug-fix, chore) starts its life on Pivotal Tracker as a new “card” ■ Usually product managers (PMs) do this (but developers can too) ■ New stories are added to the “unplanned backlog”
  29. 29. ○ A new user story (feature, bug-fix, chore) starts its life on Pivotal Tracker as a new “card” ■ Usually product managers (PMs) do this (but developers can too) ■ New stories are added to the “unplanned backlog” That means under this line! This is important!
  30. 30. ○ A new user story (feature, bug-fix, chore) starts its life on Pivotal Tracker as a new “card” ■ Usually product managers (PMs) do this (but developers can too) ■ New stories are added to the “unplanned backlog” ■ The team, led by the product manager, will decide what to do with the new task at planning time (prioritise, estimate resources, etc)
  31. 31. ○ A new user story (feature, bug-fix, chore) starts its life on Pivotal Tracker as a new “card” ■ Usually product managers (PMs) do this (but developers can too) ■ New stories are added to the “unplanned backlog” ■ The team, led by the product manager, will decide what to do with the new task at planning time (prioritise, estimate resources, etc) ■ Only stories that have been processed / prioritised / planned go over the line
  32. 32. How big is a user story? ● Stories should (in most cases) be achievable in 2-3 days.
  33. 33. How big is a user story? ● Stories should (in most cases) be achievable in 2-3 days. ○ If not, they should be split in smaller stories
  34. 34. How big is a user story? ● Stories should (in most cases) be achievable in 2-3 days. ○ If not, they should be split in smaller stories ○ In some cases, the engineer that implements the story creates subtasks that correspond to several Trello cards
  35. 35. How big is a user story? ● Stories should (in most cases) be achievable in 2-3 days. ○ If not, they should be split in smaller stories ○ In some cases, the engineer that implements the story creates subtasks that correspond to several Trello cards ...but we will talk about Trello in a minute. For now, let’s continue with the process after a user story has been added to Pivotal Tracker.
  36. 36. Parts of a user story on Pivotal Tracker
  37. 37. Parts of a user story on Pivotal Tracker A user story has four important parts:
  38. 38. Parts of a user story on Pivotal Tracker A user story has four important parts: A high-level description of the story
  39. 39. Parts of a user story on Pivotal Tracker A user story has four important parts: A high-level description of the story (Stories look roughly like: “As a [user], I want to [do something]”)
  40. 40. Parts of a user story on Pivotal Tracker A user story has four important parts: A few tags to describe the context (don’t worry about those for now)
  41. 41. Parts of a user story on Pivotal Tracker A user story has four important parts: The type of the user story: feature (new development) bug fix chore (something necessary, but that is neither a bug fix nor a new feature)
  42. 42. Parts of a user story on Pivotal Tracker A user story has four important parts: ...and the cost or the button Start
  43. 43. Starting a story ● Once a story has been added, there is a weekly meeting for Planning
  44. 44. Starting a story ● Once a story has been added, there is a weekly meeting for Planning ○ At Planning, unplanned stories (mostly those at the top of “under the blue line”) are assigned weight --- a measurement of predicted cost
  45. 45. Starting a story ● Once a story has been added, there is a weekly meeting for Planning ○ At Planning, unplanned stories (mostly those at the top of “under the blue line”) are assigned weight --- a measurement of predicted cost Cost is synonym of “effort” in this context. Some companies measure it in terms of “person * hours”. As this is futile, we just provide a relative measure in “points”: trivial stories get one point, easy stories get two points, etc.
  46. 46. Starting a story ● Once a story has been added, there is a weekly meeting for Planning ○ At Planning, unplanned stories (mostly those at the top of “under the blue line”) are assigned weight --- a measurement of predicted cost ○ These weights are used to plan sprints --- we know we can only do so much work on every sprint
  47. 47. Starting a story ● Once a story has been added, there is a weekly meeting for Planning ○ At Planning, unplanned stories (mostly those at the top of “under the blue line”) are assigned weight --- a measurement of predicted cost ○ These weights are used to plan sprints --- we know we can only do so much work on every sprint ○ Assuming a story is planned and has a weight, it is ready to be picked up.
  48. 48. Starting a story ● Once a story has been added, there is a weekly meeting for Planning ○ At Planning, unplanned stories (mostly those at the top of “under the blue line”) are assigned weight --- a measurement of predicted cost ○ These weights are used to plan sprints --- we know we can only do so much work on every sprint ○ Assuming a story is planned and has a weight, it is ready to be picked up. ○ At any point during the sprint, an engineer (sometimes more than one) will pick it up...
  49. 49. Starting a story ● Once a story has been added, there is a weekly meeting for Planning ○ At Planning, unplanned stories (mostly those at the top of “under the blue line”) are assigned weight --- a measurement of predicted cost ○ These weights are used to plan sprints --- we know we can only do so much work on every sprint ○ Assuming a story is planned and has a weight, it is ready to be picked up. ○ At any point during the sprint, an engineer (sometimes more than one) will pick it up... ○ ...and it will Start !
  50. 50. At that point, a Trello task (card) is born!
  51. 51. At that point, a Trello task (card) is born! ● A Trello card corresponds 1-to-1 to a deliverable outcome
  52. 52. At that point, a Trello task (card) is born! ● A Trello card corresponds 1-to-1 to a deliverable outcome ○ Most of the time this means code (new feature, bug fix, chore) ○ Sometimes it identifies things like blog posts or changes to the website ○ A code deliverable is developed in its own branch before merging to master. ○ Therefore there is a 1-to-1 mapping from code branches to Trello cards
  53. 53. Trello cards have three parts
  54. 54. Trello cards have three parts A description of what the task is about
  55. 55. Trello cards have three parts A description of what the task is about (Part of the description is a tag to identify the application / project that the card relates to, e.g. Global Shipping User Interface in this case)
  56. 56. Trello cards have three parts A person or team assigned to it
  57. 57. Trello cards have three parts A set of colour tags to indicate the team/s
  58. 58. Trello cards have three parts A set of colour tags to indicate the team/s (Sometimes the colour tags are also used to mark things like blocked cards)
  59. 59. The life cycle of a Trello card has five stages
  60. 60. The life cycle of a Trello card has five stages
  61. 61. The life cycle of a Trello card has five stages In Progress: all cards start here, and remain here until implemented and tested
  62. 62. The life cycle of a Trello card has five stages In Progress: all cards start here, and remain here until implemented and tested “Tested” in this context means tested locally: unit tests and integration tests passing.
  63. 63. The life cycle of a Trello card has five stages Once “finished”, tasks pass to the Code Review stage.
  64. 64. The life cycle of a Trello card has five stages Once “finished”, tasks pass to the Code Review stage.
  65. 65. The life cycle of a Trello card has five stages Every task/card must be reviewed by at least one developer (two for complex ones)
  66. 66. Developers usually inform other developers that they have finished a card and they would like a code review on Slack:
  67. 67. The life cycle of a Trello card has five stages Occasionally, cards will remain In Progress for a while if they need major changes
  68. 68. The life cycle of a Trello card has five stages Normally the code will require minor changes (or none at all) and move on...
  69. 69. The life cycle of a Trello card has five stages Normally the code will require minor changes (or none at all) and move on...
  70. 70. The life cycle of a Trello card has five stages At this point, the developer must deploy the new code on Staging (aka QA)
  71. 71. The life cycle of a Trello card has five stages Once deployed, the developer tests that everything works on Staging too
  72. 72. The life cycle of a Trello card has five stages If everything works on Staging, the card moves on
  73. 73. The life cycle of a Trello card has five stages We are almost done on Trello at this point.
  74. 74. The life cycle of a Trello card has five stages Now we have to “deliver” and “sign off”. For that, we go back to Pivotal Tracker.
  75. 75. Back to Pivotal Tracker!
  76. 76. Finishing a user story on Pivotal Tracker You may remember that everything started by pressing “Start” on Tracker
  77. 77. Finishing a user story on Pivotal Tracker Once Start is pressed, the engineer starts a task in Trello and the button changes to say Finish
  78. 78. Finishing a user story on Pivotal Tracker Once the task is Delivered / Awaiting Sign Off on Trello, the developer presses the Finish button...
  79. 79. Finishing a user story on Pivotal Tracker Once the task is Delivered / Awaiting Sign Off on Trello, the developer presses the Finish button... ...and then the Delivery button. Some companies make a distinction between “finishing” (e.g. code under review) and “delivering” but we don’t --- it’s unnecessary overhead!
  80. 80. Delivering a user story Once a story/task is “Delivered” (and marked as such on both Trello and Pivotal Tracker) it has to be verified and Accepted (or Rejected).
  81. 81. Delivering a user story Once a story/task is “Delivered” (and marked as such on both Trello and Pivotal Tracker) it has to be verified and Accepted (or Rejected). This is done by either: ● The product manager --- for user-facing cards (features, bug-fixes) ● Some other engineer --- for non-visible cards (features, bug-fixes, chores)
  82. 82. Rejecting a user story In the (unlikely, but possible) occurrence that the card is Rejected, the user story appears not-Finished on Pivotal Tracker.
  83. 83. Rejecting a user story Regarding the task on Trello, either it is fixed and re-delivered (if the changes required are minor)...
  84. 84. Rejecting a user story ...or it becomes blocked and blocks all the cards that depend on it (if any). A new card must be created In Progress for a fix and it should eventually unblock the pipeline.
  85. 85. Accepting a user story Usually, the card is Accepted. Good job!
  86. 86. Accepting a user story Usually, the card is Accepted. Good job! This is the end of the card’s life cycle on Pivotal Tracker... no more buttons
  87. 87. Accepting a user story Usually, the card is Accepted. Good job! This is the end of the card’s life cycle on Pivotal Tracker… ...but not on Trello. no more buttons
  88. 88. The job of the developer is almost done, but not quite.
  89. 89. The job of the developer is almost done, but not quite. The last step is to deploy the code to the Pre-Production servers.
  90. 90. Once the code is deployed to Pre-Production the card is move to Ready...
  91. 91. ...and its life cycle ends.
  92. 92. At the end of the sprint, all new functionality that has been deployed to Pre-Production is deployed to Production.
  93. 93. Well done!
  94. 94. Benefits of using Trello for tasks Trello makes it easy to detect a few situations that hinder productivity, including:
  95. 95. Excess of Work in Progress The number of cards on Trello should be limited. When there are too many cards, that is a symptom of having too much work-in-progress.
  96. 96. Excess of Work in Progress The number of cards on Trello should be limited. When there are too many cards, that is a symptom of having too much work-in-progress. That is inefficient. It is better to focus on finishing tasks and shipping code.
  97. 97. Excess of Work for one Person Every engineer should be present in a couple of cards in most situations. If an engineer is involved in a lot of cards it may signal that the person has too much work in progress and / or they are blocked on many fronts and need help.
  98. 98. Blockers The number of cards on Trello should be roughly equal and roughly constant in all columns as they move to the right (with the exception of the last one).
  99. 99. Blockers The number of cards on Trello should be roughly equal and roughly constant in all columns as they move to the right (with the exception of the last one). If a column starts growing in size beyond normal, that may be a symptom of one or more blockers affecting productivity. Better to solve that before starting new tasks.
  100. 100. Blocked cards Another symptom of blockers are cards not moving to the right for a couple of days. Maybe the engineer needs help? Or is the blocker somewhere else? Most cards should move to the right every day.
  101. 101. Helping progress is better than adding blockage A common mistake is to open new cards while there are still many waiting for review or sign off --- better to help moving cards to the right towards completion rather than opening new cards on the left.
  102. 102. Summary 1. First step: add new stories to Pivotal Tracker as an unplanned story. 2. At weekly planning, stories are assigned weights. 3. Once a story is Started on Tracker, a new Trello card is created In Progress. 4. When the card is implemented, it goes under Code Review. 5. When it passes the Review, it is deployed on Staging. 6. If it works on Staging, it is Delivered. 7. Once Delivered, it has to be Accepted. 8. Once Accepted, it is deployed to Pre-Production.
  103. 103. Summary --- who does what 1. First step: add new stories to Pivotal Tracker as an unplanned story. 2. At weekly planning, stories are assigned weights. 3. Once a story is Started on Tracker, a new Trello card is created In Progress. 4. When the card is implemented, it goes under Code Review. 5. When it passes the Review, it is deployed on Staging. 6. If it works on Staging, it is Delivered. 7. Once Delivered, it has to be Accepted. 8. Once Accepted, it is deployed to Pre-Production. Usually product managers add new tasks to Tracker, but developers do it too sometimes.
  104. 104. Summary --- who does what 1. First step: add new stories to Pivotal Tracker as an unplanned story. 2. At weekly planning, stories are assigned weights. 3. Once a story is Started on Tracker, a new Trello card is created In Progress. 4. When the card is implemented, it goes under Code Review. 5. When it passes the Review, it is deployed on Staging. 6. If it works on Staging, it is Delivered. 7. Once Delivered, it has to be Accepted. 8. Once Accepted, it is deployed to Pre-Production. The whole team participates in Planning.
  105. 105. Summary --- who does what 1. First step: add new stories to Pivotal Tracker as an unplanned story. 2. At weekly planning, stories are assigned weights. 3. Once a story is Started on Tracker, a new Trello card is created In Progress. 4. When the card is implemented, it goes under Code Review. 5. When it passes the Review, it is deployed on Staging. 6. If it works on Staging, it is Delivered. 7. Once Delivered, it has to be Accepted. 8. Once Accepted, it is deployed to Pre-Production. The card is created by the developer(s)
  106. 106. Summary --- who does what 1. First step: add new stories to Pivotal Tracker as an unplanned story. 2. At weekly planning, stories are assigned weights. 3. Once a story is Started on Tracker, a new Trello card is created In Progress. 4. When the card is implemented, it goes under Code Review. 5. When it passes the Review, it is deployed on Staging. 6. If it works on Staging, it is Delivered. 7. Once Delivered, it has to be Accepted. 8. Once Accepted, it is deployed to Pre-Production. The developer(s) implements the code and moves the Trello card to Under Review...
  107. 107. Summary --- who does what 1. First step: add new stories to Pivotal Tracker as an unplanned story. 2. At weekly planning, stories are assigned weights. 3. Once a story is Started on Tracker, a new Trello card is created In Progress. 4. When the card is implemented, it goes under Code Review. 5. When it passes the Review, it is deployed on Staging. 6. If it works on Staging, it is Delivered. 7. Once Delivered, it has to be Accepted. 8. Once Accepted, it is deployed to Pre-Production. ...and the code is reviewed on GitHub by other developer(s)
  108. 108. Summary --- who does what 1. First step: add new stories to Pivotal Tracker as an unplanned story. 2. At weekly planning, stories are assigned weights. 3. Once a story is Started on Tracker, a new Trello card is created In Progress. 4. When the card is implemented, it goes under Code Review. 5. When it passes the Review, it is deployed on Staging. 6. If it works on Staging, it is Delivered. 7. Once Delivered, it has to be Accepted. 8. Once Accepted, it is deployed to Pre-Production. The developer(s) addresses the comments (if any) and deploys the code to Staging...
  109. 109. Summary --- who does what 1. First step: add new stories to Pivotal Tracker as an unplanned story. 2. At weekly planning, stories are assigned weights. 3. Once a story is Started on Tracker, a new Trello card is created In Progress. 4. When the card is implemented, it goes under Code Review. 5. When it passes the Review, it is deployed on Staging. 6. If it works on Staging, it is Delivered. 7. Once Delivered, it has to be Accepted. 8. Once Accepted, it is deployed to Pre-Production. ...and verifies that everything works as it worked locally.
  110. 110. Summary --- who does what 1. First step: add new stories to Pivotal Tracker as an unplanned story. 2. At weekly planning, stories are assigned weights. 3. Once a story is Started on Tracker, a new Trello card is created In Progress. 4. When the card is implemented, it goes under Code Review. 5. When it passes the Review, it is deployed on Staging. 6. If it works on Staging, it is Delivered. 7. Once Delivered, it has to be Accepted. 8. Once Accepted, it is deployed to Pre-Production. The product manager accepts user-facing cards.
  111. 111. Summary --- who does what 1. First step: add new stories to Pivotal Tracker as an unplanned story. 2. At weekly planning, stories are assigned weights. 3. Once a story is Started on Tracker, a new Trello card is created In Progress. 4. When the card is implemented, it goes under Code Review. 5. When it passes the Review, it is deployed on Staging. 6. If it works on Staging, it is Delivered. 7. Once Delivered, it has to be Accepted. 8. Once Accepted, it is deployed to Pre-Production. Another developer accepts non-user-facing cards.
  112. 112. Summary --- who does what 1. First step: add new stories to Pivotal Tracker as an unplanned story. 2. At weekly planning, stories are assigned weights. 3. Once a story is Started on Tracker, a new Trello card is created In Progress. 4. When the card is implemented, it goes under Code Review. 5. When it passes the Review, it is deployed on Staging. 6. If it works on Staging, it is Delivered. 7. Once Delivered, it has to be Accepted. 8. Once Accepted, it is deployed to Pre-Production. The developer deploys to Pre-Production.
  113. 113. FAQ 1. How are bugs tracked at Shutl? Bugzilla? JIRA? GitHub? Something else? At Shutl, we treat bug reports in the same way that we treat all other development needs (new features, chores): we open a user story on Pivotal Tracker for high-level prioritisation and planning and we track the low-level details of the development on Trello. Some tickets (chores, bug fixes) that relate to parts of eBay that are not under Shutl’s control may use other ticket trackers (JIRA is popular). We use those to communicate with other teams in addition to other communication tools such as Slack and email.

×