Sprint Duration:
Our sprints are 2 weeks in duration, Monday to Monday.
Sprint Board:
The sprint board is the RChain board.
Estimating tickets:
The team estimates tickets using the story point method. If you find that you are unable to estimate a ticket, stop and go evaluate the work involved in the ticket. If you still find that the ticket is larger than 21 story points, then the scope of the ticket is too large. Break the ticket up into pieces that you can estimate.
Here are some articles that can help you understand the methodology:
First Approximation of mapping hours to story points*
- 1,2,3,5,8,13,21
- 1 point - approx 1 hour
- 2 - 2 hours
- 3 - half a day
- 5 - 1 day
- 8 - 3 days
- 13 - 1 week
- 21 - 2 weeks of work
* This is an approximation only. There is no intention to story point on the basis of hours. That defeats the purpose. This is only here to help describe how more points = more effort.
Ticket types:
Epic → A large feature, deliverable or body of work. Takes several months to complete. Could involve several projects, libraries, interdependent work.
Story → A feature or unit of work which can be completed entirely within 1 sprint.
Sub-task → A unit of work that needs to be completed in order to finish a story. Example: Development, create unit tests, create documentation related to a story. Typically a subtask of a story.
Bug → A defect. Bugs do not have story points associated with them. We could opt to change this in the future if desired.
Process
Prior to Entry
- Each developer will identify goals (by extension -work) planned for the next iteration. It is up to the developer to reach out to the PM or their lead if they need help.
- Everyone on the team needs to have some stretch goals planned.
- Each ticket will be sufficiently detailed such that another developer or stakeholder can understand the unit of work that is planned.
- Each ticket will be assigned story points, if applicable, an epic and release version.
- The Product Manager (if applicable) prioritizes the sprint backlog.
During Entry
- Each developer describes at a high level, what their sprint goals are.
- The Project Manager ensures that all the developers have work planned
- The project Manager ensures that all stories have estimates (story points)
- The Project Manager describes the theme for the sprint.
- The Project Manager starts the sprint.
During the Sprint
- Developers use the swim lane view to see their open tickets in order of priority.
- Developers select the top ticket in their backlog and move the ticket to "In Progress" - indicating that this is the ticket being currently worked.
- Developers complete the work described in the ticket & updates the tickets with relevant documentation, comments, etc...
- As work items are completed, associated tickets are updated until all work is complete.
- Status reports are provided during Standup meetings (3X / week - Monday, Wednesday and Friday)
- Standup Meetings
- 15 minute max duration.
- What you accomplished since the last meeting
- What is your plan between now and the next meeting
- What is blocking you.
- Discussions are side-bars - (follow up meeting is scheduled)
During Exit
- Tickets should reflect proper status (Done or not)
- All tickets should be updated with comments or documentation.
- Code should be review complete at a minimum.
- Ideally, internal demos should take place during exit or immediately afterwards (Demo what was completed during the sprint)
- Demos can be scheduled for later on also - > Demos should involve Product Management or stakeholders.
- Sprint is completed.
- Retrospective is completed.