Scrum
- https://en.wikipedia.org/wiki/Scrum_(software_development)
- Daily Scrum/Standup
-
- What did you do yesterday?
-
- What are you going to do today?
-
- Are you blocked on anything? Need help from someone?
-
- Daily Scrum/Standup
Ceremonies (planning, retros, etc.)
standup - the 16th minute is an optional last part of the standup where anyone can bring up or talk about anything
- sometimes other people like product owners etc. may be invited to standup, but in that case they might be asked to be on mute until the 16th minute.
retros should only be dev team, so its confidential
ideally you get some action items
scrum master = "servant leader"
scrum of scrums
team formation
- play a game
- get to know people as people
- working agreement
- values - what do we as a team value?
- agreements - what do we want to hold each other accountable
- cermony times
- e.g. changing the standup time due to kids, etc.
definition of done
defintion of ready
- This scrum guide is the best resource I have found to understand the scrum framework and sprints. Highly recommended. This contains a lot of the “why?” and “how?” of scrum.
Jira and Trello
We will use Jira like always as the ultimate source of truth since it integrates with a lot of our other services (GitLab e.g.). For sprints we will use Trello since it is often used in this way and excels at quick easy updates and kanban columns, etc. Trello is by the same company as Jira (Atlassian) and is often used in concert with Jira. There are built-in ways to integrate Jira and Trello together.
Sprints are often 2 weeks but can be as short as 1 week or even as long as 6 weeks. We will try with 1 week sprints for now.
Ideally what work we plan to do for a given sprint should be decided before the sprint officially starts and deviations from that should be minimized as much as possible in order to actually take advantage of the benefits of scrum such as minimizing work in progress (WIP), context switching, re-learning, etc. and thereby increasing the flow of working code/features.
Sprints start on Monday at 10:30 where we have a Sprint Plannning meeting and end on the next Monday at 10am where our standup finalizes what cards are officially done or not done.
Daily Scrum/Standup Meeting
- Each person updates their Trello cards in sprint
- For the standup, update the cards you are working on so they are in the correct column (in progress, testing, blocked, etc.)
- For the standup, update the cards you are working on so they are in the correct column (in progress, testing, blocked, etc.)
- Each person gives an update on all the cards you have “in motion” (in progress, testing, blocked)
What did you do yesterday?
- What are you going to do today?
- Are you blocked on anything? Need help from someone or some thing (dependency on another issue e.g.)?
- As a team, move cards in Review to Done
- As a team, try to clear any cards in Blocked
Let’s try to keep each person’s updates not much more than a couple minutes long. Mainly just updating the in progress Trello cards and mentioning blockers. And then we can sidebar more in-depth conversations for after the standup. Meeting should be about 15-30 minutes tops.
Weekly Sprint Planning Meeting
Decide what work to do in the next sprint. Decide on Sprint Goal. Decide on what cards we want to commit to get done that Sprint and put them in the Sprint Backlog. Use Product Backlog cards as high-level guidance. Make sure cards are Agile-style increments of work with clear definition of done and a deliverable artifact (Merge, approval, passing tests, etc.)
Weekly Sprint Review & Retrospective & Demo Meeting
Demo what we accomplished that sprint.
Review what got done, what went well and what didn’t. What can we adapt for the next sprint?
Trello/KanBan Card/Issue Statuses/Columns
- Icebox
- Cards we think might not need to be done anymore. Cards we’re not 100% sure should be deleted (there’s a chance they will eventually become relevant again but not for the foreseeable future).
- Cards we think might not need to be done anymore. Cards we’re not 100% sure should be deleted (there’s a chance they will eventually become relevant again but not for the foreseeable future).
- Inbox
- Anyone can add what they think needs to be done at some point. Maybe a bug, idea for feature, a derivative/related task that arises out of another card you’re working on etc.
- Everyone’s general responsibility as far as speaking up for a feature or bug that might need to be added to the product or sprint backlog.
- Doesn’t necessarily need a Jira ticket - if we promote a card from Inbox to Product or Sprint Backlog or In Progress, etc., it needs to have a Jira ticket.
- Anyone can add what they think needs to be done at some point. Maybe a bug, idea for feature, a derivative/related task that arises out of another card you’re working on etc.
- Product Backlog
- Product owner(s) responsibility. Maintained by product owner (product owner is the only person modifying this).
- What the product needs - features, bugfixes, etc.
- Ideally already in the form of focused user stories that are ready to be added to a sprint and worked on, but might need to be more general high-level product goals or epics.
- Ordered list, by priority.
- What we start to draw from when planning the next sprint.
- The most common type of item on a product backlog will be user stories
- In simplest terms the product backlog is a to-do list for the team – a list of all of a product’s features in priority order.
- https://manifesto.co.uk/agile-concepts-product-backlog/
- Product owner(s) responsibility. Maintained by product owner (product owner is the only person modifying this).
- Sprint Backlog
- Scrum master’s responsibility. Maintained by scrum master (scrum master is the only person modifying this).
- Ideally in the form of focused user stories with clear definition of done/acceptance criteria with some kind of deliverable that can represent it’s status (PR, passing tests, document created, someone signing off/approving something).
- Scrum master maintains this column, but when the sprint starts, any developer can pull any card from the sprint backlog to start working on.
- Cards added to this column should:
- be an Agile-style, incremental unit of work with a clear “Defintion of Done”/acceptance criteria.
- Have a Jira issue attached to it.
- Have a product label attached to it (POSS, MCP, etc.)
- In general, shouldn’t be assigned yet so that theoretically anyone can pick up the card and work on it.
- be an Agile-style, incremental unit of work with a clear “Defintion of Done”/acceptance criteria.
- Ordered list, by priority
- Scrum master’s responsibility. Maintained by scrum master (scrum master is the only person modifying this).
- In Progress
- Working on today
- Working on today
- Blocked
- By people, dependencies, or things
- E.g., waiting to hear back from something on something or waiting for another card to be done or waiting for access to a repository or hitting a brick wall on a technical problem and need help.
- By people, dependencies, or things
- Testing
- You think it’s done, the central engineering problem seems to be solved, but you still might need to clean up the code and run or write tests or fix a build problem in the pipeline, etc.
- Verifying
- with testing or SMEs or stakeholders
- with testing or SMEs or stakeholders
- Integration
- e.g., running integration tests in the pipeline or deploying to a dev/qa/staging environment to check functionality, or fixing a build issue.
- e.g., running integration tests in the pipeline or deploying to a dev/qa/staging environment to check functionality, or fixing a build issue.
- Deployment/building, dev/staging environment, etc.
- You think it’s done, the central engineering problem seems to be solved, but you still might need to clean up the code and run or write tests or fix a build problem in the pipeline, etc.
- Review
- Approval/acceptance/socialize
- When you think all of the acceptance criteria is done on a card, the card should go to the review column so it can be socialized/shared and the team owns what counts as done.
- When you think all of the acceptance criteria is done on a card, the card should go to the review column so it can be socialized/shared and the team owns what counts as done.
- Clear procedure for moving to Done
- E.g., at daily standup - shared that something is done and team moves it done.
- E.g., at daily standup - shared that something is done and team moves it done.
- Approval/acceptance/socialize
- Done (for a given sprint)
- Team responsible for what gets put in Done column, but ultimately scrum master’s responsbility to look after and be accountable for what is actually done each sprint.
Definition of Ready & Definition of Done/Acceptance Criteria
Definition of Done
What counts as done for a given card will vary. Below are some examples we should think about for each card.
- Testing
- local testing
- pipeline testing
- builds completing
- integration testing
- local testing
- Documentation
- update readme, comment code, confluence, ZenDesk article updates
- update readme, comment code, confluence, ZenDesk article updates
- PR
- PR template
- Code review
- Approval
- PR template
- Merged/Deployed
- Some deliverable artifact to represent the card (Merged PR, passing test, verified approal email, etc.)
Each card’s definition of done should be completed before it can get moved from review to done.
Definition of Ready
Each card needs to meet the Definition of Ready before it can officially be added to a Sprint’s backlog.
- Is it a small enough increment of work?
- Does it have a clear Definition of Done/ccceptance criteria added to the card?
- Is there a delieverable artifact to represent the card being done? (PR merge, document, etc.)
- User stories
- As a, I want to x, so that x
- As a, I want to x, so that x
Sprint Tracking
I.e., how to track each sprint’s goal, plan, and what actually got done
I don’t think Jira has the ability to do 1 sprint across multiple projects
Potential Solutions:
- Track completed sprints in a “Completed Sprints” Trello board
- simplest and easiest
- simplest and easiest
- Other paid SaaS products like:
- Unify our development team onto one Jira project - “Revlogical” e.g.
- Still use Trello for Sprints and then sync up with Jira at the start and end of a Sprint
- Still use Trello for Sprints and then sync up with Jira at the start and end of a Sprint
Product Owner Role
Decides Product Goal(s)
Decides what goes in to Product Backlog and its order/priority
Responsible for product
Helps clarify definition of done/acceptance criteria for cards
Scrum Master Role
Works with Product Owner to decide Sprint Goal and what goes into Sprint Backlog
Decides how to accomplish Sprint Goal and the cards'/issues' priority
Responsible for sprint and what gets done
Helps clarify definition of done/acceptance criteria for cards in sprint
Helps developers clear blockers and handle bottlenecks, complications, logistical issues, minimizing work in progress, etc.
Kind of an air traffic controller type role.
Developer
Works on cards in the sprint
Responsible for cards they pick up - completing the card’s definition of done/acceptance criteria, updating cards' status (In progress, testing, blocked, etc.)
Contributing to scrum meetings - daily standup, weekly sprint demo/review, & weekly sprint planning
Shared ownership of sprint - help with collaboration and clearing blockers, etc.# Scrum