The Scrum Board

Triage

Triage - (medical) the assignment of degrees of urgency to wounds or illnesses to decide the order of treatment of a large number of patients or casualties.

When a bug or feature is first introduced, it goes into the triage category. Before it can be moved into the “Ready for Development” category, it must go through a few steps to ensure that the issue exists and is clearly defined. Moving a bug from “Triage” into “Ready for Development” is something that should be done as a team before a particular person puts their name on it.

Bugs

1. Reliably reproduce it
2. Update the bug description on Github if needed If the bug isn’t a problem, and it can be removed from the board immediately Else, make sure the bug is well defined
3. Bring up the bug at the next stand-up Summary of the investigation so that everyone is aware Answer all questions If needed, the group can reassign it to a different category on the board

-Features 1 Make sure the feature is well defined 2 Update the bug description on Github if needed 3 Bring up the bug at the next stand-up -Summary of the feature so that everyone is aware -Determine if feature is necessary and valuable -Answer all questions -If needed, the group can reassign it to a different category on the board

Once the issue is well defined, it is said to be “groomed”. The process detailed above where the whole team discusses and defines the issue is known as grooming. Perhaps we can set up a separate meeting for this, or do this after standup. Separating this process from standup can make the actual standups faster.

Ready for Development

Once an issue is ready for development, any member of the team should know enough about the problem to start working on it (having the skills to do so is a separate matter).

Once someone decides that they would like to work on an issue, they should set up a meeting with a more senior team member to discuss how to solve the problem. You can discuss possible solutions, write things out on a whiteboard, develop flow charts, list out useful resources or functions, etc. This meeting is a design meeting. After the design meeting, the actual work involved in fixing the bug or adding the feature should be all planned out. The design meeting can have as many/few people in it as the person working on the bug wants.

After the design meeting happens, you may put your initials on the bottom left corner of the issue on the scrum board, and move it from “Ready for Development” into “In Progress”.

In Progress

As long as you are working on resolving the issue, the issue stays in the “In Progress” column. Once you pull something into this column, you are responsible for finishing it as quickly and effectively as you can. Some rules to live by once you have a piece of work in this column:

Move this issue out of this column as quickly as you can Do not pull in other work while you still have existing work in progress unless A high priority issue comes up that is more important You are blocked and have nothing else to do

You should have at most three items with your name on it in the “In Progress” column, otherwise you are spread too thin, and are hogging work that somebody else could be doing. If you keep pulling in issues because you are blocked and have more than three, you aren’t being aggressive enough asking the rest of the team for help getting unblocked.

If you are blocked, this means there is some obstacle, usually a lack of knowledge, impeding your progress on an issue. If you are blocked on something, mention it at standup, or seek help from another team member as soon as you can. To signal that you are blocked on an issue on the scrum board, rotate the sticky note with the issue on it so that it looks like a diamond rather than a square. If you see on the scrum board that someone is blocked on an issue, make an effort to ask after the problem and try and help resolve it. Once you are unblocked, you can move the sticky back to its original position.

You finished working on your issue and everything seems to be working. Great! But before moving it into code review, you need to make sure that your work meets the definition of done. The definition of done is a checklist of items that must all be completed for an item of work to be officially considered “done”. Our definition of done includes the following items:

Code complete Any new unit/integration/functional tests are written All unit/integration/functional tests pass Issue solves the actual problem Well documented

Once you feel comfortable that your work meets the definition of done, make sure all your changes are pushed up onto your branch in Github, and then put your issue into the “Code Review” column.

Code Review

The code review process is further outline at the below link. Follow all guidelines appropriately. https://github.com/isenseDev/rSENSE/wiki/Reviewing-Pull-Requests

Done

Congratulations! Once your code passes code review, you are done! Move your issue into the “Done” category. At the next standup, take a few minutes to demo your changes to the team, making sure to get everyone’s, especially Fred’s (if it’s a major change), approval.

The team releases every two weeks, and the issue should remain in this category until the fix is live. After releasing, all the issues in the done category can be removed from the board.

Standup

Standups are very quick meetings which are timeboxed to about 15 minutes. In each standup, every team member answers these three simple questions:

What did you accomplish since the last meeting? What are you working on until the next meeting? What is getting in your way or keeping you from doing your job?

This tells the team exactly what is getting done and what needs improvement. Listing any problems or issues you may have is crucial, so that your team will know to help you out. Small problems should always be addressed so that they don’t turn into big problems.

Question one should be answered very quickly. The bulk of the time each person spends talking should be regarding current tasks and blocks they are facing.

Post Standup

After standup, take the time to:

Do grooming on any issues that need triage Have team members demo finished work

This section is informal. It has been separated from standup to make standup shorter, so that if people need to leave early, they can. All team members should be present for grooming. It would be nice if all team members were present for demos, but Fred is the main person that you should be demoing to, so he is the only person “required” to attend.