# Bitmark Distributed Scrum Guide

Our goal is to enable distributed, asynchronous product development using traditional scrum / agile methodoligy.

* At Bitmark, we use Scrum framework to develop products in a way that we make them less wrong over time. In that,
* We believe knowledge come from experience
* We make decision based on what is known
* We use 2-week cycle called Sprint to keep learning about the Product and sharpen our decision. In that,
* We set the goal and forecast the work to be done at the begining of the sprint, in "Planning meeting".
* We do team update everyday, foresee any impediments to tackle, in "Daily meeting".
* We review the new state of the product (called increment) at the end of sprint, in "Review meeting".
* We review and learn to work better for the next sprint, in "Retrospective meeting".
* For the sprint to be successfully executed, we need a number of roles. In that, we need
* One Product Owner, responsible for maximizing the business value of the product delivered by development team effort.
* One cross-functional development team, responsible for doing the work to move the product to the next increment.
* One Scrum master, responsible for helping everyone keeping the process right.
* To help with the efficiency of learning from experience, our work are all visible via
* A wish list called Product Backlog that we want our product to have
* A list of solid, refined "wish" written in the form of "user story" that we are going to execute in the next sprint, called "Sprint Backlog"

## Meetings

### Planning
_24 hours max_

* Product owner explains the goal of the sprint.
* Product owner defines the user stories on Product Backlog, with each, each development team member clarifies the scope and writes what they need to do.
* Scrum master sends out anonymous voting form to the development team, each team member votes on how much effort the team will spend on finishing the story. The unit of estimation is 1 (half day), 2, 3, 5...
* Everyone has to vote, not matter you are designer/QA/developer/writer.
* If the voting is conflicting too much, the bigger one try to convince the smaller one why it's big.
* We vote again if someone get convinced, or if it takes too long, we just go with majority and we will learn.
* Only development team can decide how much effort it needs to finish the story.
* If the effort to finish a story is unexpected, unacceptable to the PO, we
* PO and development team discuss to see if we understand the scope the same, if not, we correct it.
* If the effort is still high, the PO helps by reducing the scope, breaking down the stories, try to keep the business value high, or considering remove other stories.
* Development team moves stories from Product Backlog to Sprint Backlog, the sprint starts.

### Daily
_One-minute max per video_

* Each person answers 3 questions while other paying high attention
* What did I do yesterday to help our team reaching sprint goal?
* What will I do today to help our team reaching sprint goal?
* What impediment do I see that might stop us from reaching sprint goal?

* Scrum master makes sure videos are recorded and watched first thing in the (local-time) morning of each team member.

### Hand-off
_Post in Slack channel end of the day_

* Each person informs other team members what has been done so that other team members can continue their work; also remind other team members what needs to be done before you can start your work tomorrow.

### Demo
_24-hours max_

* Development team records a video demo for the Product Owner and other Stakeholders.
* The PO gives written or video feedback on what has been implemented, and makes a decision to ship the work.
* The PO then consider changes for Product Backlog based on what he/she learnt from the demo

### Retrospective
_24-hours max_

* Scrum master, with the help from everybody, summarize the events and decision made during the sprint in a Google Doc using the Standard Template.
* Everybody then imaging if we can do the sprint again and answer
* What they would do the same?
* What they would do differently and what different result they would want to achive?
* Scrum master chooses 3 improvements to make in the next sprint

## Working guideline

### Best practice

* PO provides wireframe and review it with development team before planning meeting happens
* Each story must have
* Title for quick and easy to remember
* User Story to express the business value clearly
* Wrireframe/UI that is enough for the team to understand
* During first half of the sprint, the team makes room to move the last increment to production
* Designer tries to move as fast as possible at the begining of the sprint to remove UI dependencies
* Developers tries to implement on mock up design if possible at the begining of the sprint, get ready for real UI coming
* Developers are responsible for functionality & UI implementation, testing, designers are responsible for helping with UI testing

### Daily work issue resolving

* If we can not estimate some stories because of lacking knowledge, do we start the sprint?
* We still start sprint as long as we have stories to do for the first half of the sprint.
* During the first half, PO will spend time to refine the stories that important to finish for the goal as a highest priority activity.
* PO tries to avoid this happening next time as it increases the risk of achiving the goal.
* I have stories to finish, but someone report bugs on production, what should I do?
* Bugs are fixed immediately as they are found and less than 1 point to fix
* If it costs more than one point, consider:
* If it's very critical bug (use your sense), fix first, and ask everyone for help to cover the work (including the PO, to reduce the scope of stories)
* If it's minor, and you don't have time, ask the PO for him to make decision, and may consider it in the next sprint
* I have stories to finish, but business/CEO/stakeholders askes me to work on something else
* Ask PO to deal with them
* If the PO agrees to do, he/she must consider if sprint goal is affected
* I realized that the story is more complicated, it costs me more time
* Raise your hands asap, so that the team can help you to cover
* Ask the PO for making decision on the scope, or changes to other stories
* Tell the Scrum Master to take notes on the events and decisions to learn for next sprints