class: center, middle # Automatic Project Management Ben Christel, 2023 .deemphasized[This presentation was made with [Remark](https://github.com/gnab/remark).<br>To see the speaker notes, press `P`.] ??? These are the speaker notes! --- class: center, middle # Automatic Project Management with  Ben Christel,  2023 Khan Academy --- # Outline - Why I'm giving this talk -- - What is Tracker? - Live demo -- - What is Tracker for? -- - The Tracker Process -- - User Stories -- - Estimation -- - Problems with Tracker --- # Why This Talk? -- - We're in a transitional period -- - This isn't a sales pitch - I don't think we should use Tracker -- - This talk isn't really about Tracker, the software product -- - It's about a way of approaching project management that's worked really well for me. -- - I don't even think we should use the whole Tracker _process_. -- - I _do_ think the process is worth studying and learning from. --- class: center, middle # What is Tracker For? --- .breadcrumb[What is Tracker For?] # Tracker is like Jira -- - Features and Bugs -- - Epics and labels -- - Story points -- - Velocity --- .breadcrumb[What is Tracker For?] # ...but Tracker is *not* Jira -- - One view of the project. Everyone on the team sees the same thing when they look at Tracker. -- - live-updating UI, collaborative UX -- - No sprint commitments. One continuous flow of value. -- - Work items have no “Priority” field\* -- - Work items can have up to 3 owners. This enables pair programming. -- - Completed work items can easily be browsed later and form the internal documentation for the project --- class: center, middle # (Live Demo) ??? Live demo: https://www.pivotaltracker.com/n/projects/2548896 - Backlog of prioritized work, icebox of unprioritized work - Highest-priority at the top - Velocity is the average number of story points the team gets done per week - Gray markers are week boundaries—automatically placed based on velocity - You can easily see what's probably going to get done each week - star = feature, gear = "chore", bug = bug - as work gets done, it moves from "unstarted" state to "started", "finished", "delivered", and "accepted". --- class: center, middle # What is Tracker For? --- background-image: url(automatic-planning.png) background-size: contain background-repeat: no-repeat ??? Automatic planning keeps your team in a rhythm. Get predictable and stay that way: Say goodbye to managing timelines and meeting unrealistic expectations, and let velocity do the planning. --- .breadcrumb[What is Tracker For?] Tracker made it easy for us to answer questions about the health of a project, with data. -- - When will feature X be done? -- - How much work can we realistically get done this week? -- - Where are the bottlenecks? -- - Is the team getting more or less effective over time? -- - Who worked on what? -- - How many people would we have to add to the team to make our planned release date?\* -- - Why did we make the technical decisions we did? --- class: center, middle ### Tracker also enabled a particularly effective work process. ??? But the value of tracker doesn't stop at planning. For us at Pivotal, it enabled a particularly effective way of working. --- class: center, middle # The Tracker Process --- .breadcrumb[The Tracker Process] ### One Queue, Many Cash Registers  --- .breadcrumb[The Tracker Process] ### One Backlog, Many Workstations  --- class: center, middle #### When we finished a task, we'd pick up whatever was at the top of the backlog and work on that next. --- .breadcrumb[The Tracker Process] # Advantages of the one‑backlog model - The top-priority thing is always being worked on - No time is spent assigning work to people - Everyone has something to do - You get to work on a variety of things - Everyone is working on only one thing at a time --- .breadcrumb[The Tracker Process] # Risks of the one‑backlog model - What if I don't know how to do the highest-priority thing? - What if it's not my area of the codebase? - What if I don't know what the requirements are? --- class: middle Pivotal addressed these risks by pair-programming full time. - We switched pairs daily to maximize knowledge-sharing. ??? When we switched pairs, one person would stick on the current task to keep context. Sometimes the person who'd been on the task longest would switch out, sometimes they'd stick. --- .breadcrumb[The Tracker Process] # The lifecycle of a task -- - Unstarted -- - Started (a programmer's working on it) -- - Finished (code written, tested, and integrated) -- - Delivered (deployed to a staging environment) -- - Accepted (PM / QE signed off) -- - ...or Rejected (needs more work) -- - Released to users! (not represented in Tracker) --- class: center, middle # User Stories ??? I should say more about the internal structure of these tasks. Tracker calls them user stories. --- # User Stories - “Features” -- - The smallest useful increment of functionality -- - “Minimum viable feature” -- - Something a user could test and give us feedback on -- - A way of phrasing software requirements so everyone on the team can understand them --- .breadcrumb[User Stories] ## Parts of a (User) Story -- - The motivation: a goal, problem, or conflict. -- - The protagonist: a role or persona. -- - The plot: what specifically does the user do? - this gives us the start of a test plan - A.K.A. Acceptance Criteria -- - Illustrations: design mockups or sketches. --- class: center, middle # Motivation --- .breadcrumb[User Stories > Motivation] ## “As an X, I want to Y, so that Z” _As a product manager, I want to click and drag stories to reprioritize them, so I can effortlessly communicate priorities to my team._<br><br> -- _As a developer, I want to click “start” on a user story and have it update for everyone, so that no one else also starts working on it._<br><br> -- .deemphasized[This pattern is named the [Connextra Template](https://www.agilealliance.org/glossary/user-story-template/), after the first company to use it.] --- .breadcrumb[User Stories > Motivation] # Bad User Stories  --- .breadcrumb[User Stories > Motivation] # Bad User Stories  --- class: center, middle # Protagonist --- .breadcrumb[User Stories > Protagonist] # Roles - The capacity in which someone is using your product. -- - Different roles have different goals. -- - Examples: - Teacher - Parent - Learner - Donor - District Admin - Discussion Moderator - Content Author - ... ??? A person is not their role. A given user can move between roles and even occupy multiple roles simultaneously. --- .breadcrumb[User Stories > Protagonist] # Roles for Pivotal Tracker - Product Manager - Designer - Engineer - IT administrator - ... --- class: center, middle # Plot --- .breadcrumb[User Stories > Plot] # Acceptance Criteria - A test plan that we write before the work starts - Ensures that the feature can actually be tested! I.e. it actually has some reliable, perceptible effect from some user's perspective. - “Acceptance” means the PM or QE running through the test plan and signing off on the work. --- .breadcrumb[User Stories > Plot] # Gherkin - A semi-structured language for writing acceptance criteria - GIVEN, WHEN, THEN ```gherkin Given I am logged in as an admin When I visit "/devadmin" Then I see a link titled "Content Editor" When I click "Content Editor" Then I am taken to "/devadmin/content" And I see a list of courses ``` --- .breadcrumb[User Stories > Plot] # Gherkin - GIVEN = preconditions. "Arrange" - WHEN = action. "Act" - THEN = how you know it worked. "Assert" --- class: center, middle ***Communicating requirements is more important than syntax!*** ??? Gherkin was invented as a semi-structured language for writing user acceptance tests. The idea of a user acceptance test is that a non-technical person (the user or customer) writes them in Gherkin, and then developers work behind the scenes to translate the Gherkin statements into executable code using templates. There are tools for doing this, e.g. the Cucumber testing framework. The problem with acceptance tests is that customers and users don't seem to care about them in practice. --- class: center, middle # Putting it all together --- .breadcrumb[User Stories] # User story example > Feature: User story workflow button > > As a developer using Pivotal Tracker, I want to let my team know what story I'm working on, > so that no one else also works on it. > > **Given** I am logged into Tracker<br> > And my project has a user story that is not yet started<br> > **When** I click the "start" button on the story<br> > **Then** the button turns blue<br> > And the text changes to "deliver"<br> > And the background of the story card changes to yellow, meaning "in progress" > > **When** I log in as a different team member<br> > **Then** I still see that the story is in progress --- .breadcrumb[User Stories] # User story example, cont'd A design mockup is worth a thousand words.  --- .breadcrumb[User Stories] # Advantages of writing stories this way - each piece of work creates demonstrable value for an identifiable segment of your audience (the persona) - the scope of the work is clearer to everyone involved --- .breadcrumb[User Stories] # Risks of writing stories this way - using the template without fulfilling its purpose - waste of effort when the team already knows what to do - the "fog of formality" from the structured format can make the story _harder_ to understand --- .breadcrumb[User Stories] # Break the rules _A user story is a **placeholder for a conversation**._ > We have come to value individuals and interactions over processes and tools. > > —The Manifesto for Agile Software Development --- class: center, middle ***Story-writing is a process, not a single step*** --- ## What about work that isn't a user story? -- - Bugs -- - Do not get estimated - _Do_ go through the delivery/acceptance workflow, like features -- - Chores -- - Internal developer tasks - Do not get estimated - Do _not_ go through delivery/acceptance (since they're not user-facing) --- # Estimation - Tracker measures the relative "size" of work items in **story points**. -- - Story points combine estimates of risk, complexity, and effort, all of which correlate with time. -- - While we're bad at estimating how long something will take, estimating _relative size_ is easier. -- - A team, working sustainably over time, will deliver a fairly consistent number of story points every week. The average story points per week is the team's _velocity_. --- .breadcrumb[Estimation] # Estimation  ??? To avoid quibbling over story points and decouple estimates mentally from time, Tracker forces estimates to be approximate by "bucketizing" them into a small set of values. --- .breadcrumb[Estimation] # Estimation Several point scales are in use: - linear: 0, 1, 2, 3 -- - fibonacci: 0, 1, 2, 3, 5, 8 -- - exponential: 0, 1, 2, 4, 8 -- - sparse fibonacci: 0, 1, 3, 8 -- - custom: 1, 5, 25, 125 -- The only thing you can't do in Tracker is make the "estimate" field a free-entry number input. --- .breadcrumb[Estimation] # Why estimate? -- - Predict how long a whole project will take -- - Predict when a given feature will be ready -- - Have a conversation about what's involved in implementation --- .breadcrumb[Estimation] # \#NoEstimates -- A team has a velocity - an average number of story points they deliver per week. -- A team also has an average story size. -- Divide velocity by story size, and you get stories per week. -- If velocity is stable, and average story size is stable, then counting stories should give you the same long-term forecasts as estimating with story points! -- ...but this doesn't work as well for short-term forecasting. --- .breadcrumb[Estimation] # Bugs - Bug reports do not get estimated! Why? -- - It doesn't make sense to count bugs towards velocity. -- - Imagine we _did_ estimate bugs. -- - Say our team did 7 points of user stories this week, and 3 points of bugs. -- - There are 100 points of user stories before our next release. -- - When should we expect the release to be ready? -- - If we assume bug reports come in at a roughly constant rate, the team will only be able to get 7 points of scheduled work done each week. So the release will ship in 14 or 15 weeks, not 10. --- .breadcrumb[Estimation] # Chores technical tasks - "renew the SSL certificate" - "set up GitHub Actions to run the tests for every commit" - "rewrite half a million lines of Python in Go" Chores are not estimated, for the same reason bugs are not—they're emergent work that "bubbles up" from the dev team, rather than being dictated by the business. --- class: center, middle # Problems with Tracker --- # Problems with Tracker - Engineer-centric. Designers get left out. There's no "in design" state for user stories. -- - The one-backlog approach works best for co-located teams, working on small codebases. --- # Reflection What (if anything) seems like it could be useful to us? --- class: center, middle Thanks for listening!