Sprint Process

We are using the Agile development methodology as our project management process. You can read up on Agile here: https://www.codeproject.com/Articles/604417/Agile-software-development-methodologies-and-how-t

Pro's and Con's of Agile

Pro's:

Work must be broken down into sprint sized blocks of work.
Encourages development of more modular pieces of work → if done correctly, leads to better design of code (smaller modular pieces, with wholly contained functionality)
Estimating smaller pieces of work tends to be more accurate
Encourages developers to plan out their work in advance of entry
A sprint once started, should not be adjusted. This keeps stakeholders from interrupting work in progress

Con's:

Could be a tendency to skip the requirement, specification and design steps for large features or green field projects.
Stakeholders/Requirements that are not managed well, waste developer time with frequent changes. (False belief that requirements are fluid)
Tendencies to skip the documentation, testing or code review processes.
Focus on demo's

Our Mitigations:

To the extent that is possible, we will strive to clarify requirements and questions prior to pulling a ticket in the sprint.
If we make an assumption or decision, we will document them in tickets and wiki's/
We will allocate time in our sprint planning for specification, research and design and will provide artifacts as proof of work for those tasks.
We will focus on delivering shippable, working code to the community in lieu of demos.

Snapshot of Agile Versus Waterfall

Agile places value on smaller increments of delivery.

*Source: https://www.codeproject.com/Articles/604417/Agile-software-development-methodologies-and-how-t

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.