---
# System prepended metadata

title: VA Core Team Discussion
tags: [AGILE, SCRUM]

---

# VA Core Team Discussion

###### tags: `SCRUM` `AGILE`

#### 2022-2-15 Conversation on best practices to increase velocity


## Sprint Planning 📈
- Each project should have a sprint goal
    - before we start planning - team get together to be on the same page
    - Have a functioning API
    - See an order come in
    - For EACH project being worked on
- Start the sprint with the expectation we are going to finish the sprint with no **TODOs** and can pull in from backlog 
- Seperate tasks for Frontend and Backend (add labels)
- Moving to smaller Pull Requests
- Bugs should start at 0pts as we they are 'our fault' so to speak.
- Assign tasks to team members during sprint planning 
- After a large release we would like to leave space in the following sprint for bugs/issues
    - May change: let's leave 7 points free
    - Make sure backlog is prioritzed
- [VA Board](https://digicertinc.atlassian.net/jira/software/projects/VACORE/boards/411) 

## Sprint Grooming 🐩
- We cancel when the PM's do not have anything, but the team would like to use this time to sort and prioritize the backlog, discuss scope, etc
    - Could PMs message the team chat that they don't have anything for pre planning/grooming, and the team can then voice if they have anything they would like to go over, such as scope or general questions?
- Prior to grooming, could the PMs send out an agenda of items that wil be discussed during grooming? slack/email?
    - Team can then review items and prepare any questions

## Story point estimating 📚
- Estimating as a team to encourage discussion
(https://digicertinc.atlassian.net/jira/software/projects/VACORE/boards/411)

## Github PRs 🎭
- Tighter relationship between branch naming and ticket names
- Use one naming conventon for branch naming
    - "VACORE-123-descripiton-here"
    - But if no ticket name - short lived branch such as "fix prod"
- Make it a standard that unit tests are a requirement before a Jira ticket can be considered **DONE** 
    - If unit tests apply
    - If requires the use of DB - integration tests
    - Documentation be included
        - ex: new endpoint? new postman collection!
    - Make sure your teammates are not second guessing how to read/spin up code
    - Think about long term maintainability

### Pull Request Template Example

```
# Description

**What was changed?**

**What is new?**

## Checklist

- [x] Code was run locally
- [x] Tests were run locally
- [ ] Necessary tests were added
- [ ] Updated API documentation (Postman/API docs)
- [ ] Added logging
- [ ] README, comments, documentation, descriptor
- [ ] Verified changes are compatible w/ local dev environment(s)
```

## Jira Templates 🀄
- Title Template: [Tool] Title
    - AUD
    - WFM
    - PROS
    - etc
- Jira description or it didn’t happen
    - Needs to includes a description with a user story or other updates
    - Acceptance criteria 
        - Accuratley define **DONE**
- Do not add to Jira description once in sprint/ do not change ticket when in sprint
    - No tickets should be altered once in the sprint
    - This will change the scope/story points
    - Add a comment 
    - Create a new ticket
    - BIG CHANGE - then scrap the sprint for pure AGILE
- Anything discussed for the ticket should be documented in the ticket
    - Comments are a greta way to show ticket progression
- Description should be up to date with all the details needed to complete the task
    - If it’s not, then as a team we should agree to not pull it into the sprint until it’s ready with the above details
    - If technical work: technical description.  What are we trying to solve for this specific piece of the puzzle?
    - Put technical stuff in comments (nice to have)
- [RA Team Jira Templates](https://digicertinc.atlassian.net/wiki/spaces/PKIRA/pages/703270787/Jira+Templates)

### Jira Template Example
```
### User Story

As a ___, I want to ____ so that I can ___.

### Acceptance Criteria
* some
* acceptance
* items
```

## Definition of Done 🏁🏁🏁
- Establish a definition of done that we follow when approving and merging code changes
    - Documentation
        - New endpoints
        - Workflows
        - Instructions how to set up and run
        - Are there any gotchas?
        - Support Documentation (Ops Coordination - ie [WFM](https://digicertinc.atlassian.net/wiki/spaces/VAL/pages/5475992049/Workflow+Manager))
    - Testing is completed
    - Logs are added
- [RA Team Definition of Done](https://digicertinc.atlassian.net/wiki/spaces/PKIRA/pages/1151271163/Definition+of+Done)


## Small fixes and QA 💽
- Establish a flow for all fixes and include a QA process.
    - Post-op any outage
        - What happened? "[5 whys](https://www.mindtools.com/pages/article/newTMC_5W.htm)"

## Team
- Have at least a descriptive line and/or links to jira(s) when sending out a meting invite
- Feel free to leave any questions or feedback
- Standup Suggestion: 
    - popcorn to teammate, to quell Sam's anxiety
    - Friday after standup have a little bonding time
        - 2 truths and a lie
    - 