I want to improve flow at work. I think the most pressing thing is that we don’t adapt often enough our process. This is good and bad at the same time. Maybe SCRUM can help.
scrumtrainingseries.com has some great videos on scrum, all around 15 minutes: http://scrumtrainingseries.com/
The first introduction video with 17 minutes as a starter which I can really recommend. It gives overview over roles, meetings and artefacts: http://scrumtrainingseries.com/Intro_to_Scrum/Intro_to_Scrum.htm
The roles are:
- Development team: Cross-functional group able to develop a shippable feature, collaborates, self-organizing, 5-9 individuals
- Product owner: Responsible on Return Of Investment (ROI); Prioritize backlog, gives product vision
- Scrum master: Has no management authority, doesn’t have project manager role, is a facilitator, helps the team
The meetings are:
- Sprint planning: Development team draws cards from the backlog and discusses coarse technical road.
- Daily scrum: Short 15 minutes stand-up meeting of the development team. Everybody of the team reports to each other.
- Sprint review: Development team shows all features to the product owner and stake holders.
- Sprint retrospective: The development team discusses about what went good, what went bad and what might be improved for the next sprint.
- Backlog refinement meeting: Product owner and team tries to take a look in the future and try to order the backlog. Find dependencies, etc.
The artefacts are:
- Product backlog: Includes all user stories sorted by priority. Does not contain tasks!
- Sprint backlog: backlog items where the development team committed to do in the sprint
Sprint planning meeting
In the scrum master facilitated time-boxed meeting, the development team and the product owner will agree to sprint goals.
In the first part of the meeting, the development team commits on implementing to the top feature cards from the product backlog. In the second part, the features will be broken into tasks. It’s OK if only 60% of the tasks are known upfront. A task should be less than one day for one person to work on.
The meeting should last around 2 hours per week of sprint. So when doing two weeks sprints the meeting should last 4 hours.
The development team should also agree on a definition of done which means when a card is finished. This should at least include: properly tested, refactored, potentially shippable.
A great intro to spring planning can be found here: http://scrumtrainingseries.com/SprintPlanningMeeting/SprintPlanningMeeting.htm
Daily scrum meeting
The daily scrum meeting is same time same place every day stand-up for only 15 minutes for the development team. It should encourage team collaboration. Every team member should quickly answer the following questions in front of all others:
- What did I do yesterday?
- What will I do today?
- What impediments blocking progress?
It’s up to the team if the product owner should attend or not.
How the daily scrum could look like is described here: http://scrumtrainingseries.com/DailyScrumMeeting/DailyScrumMeeting.htm
Sprint review meeting
In the sprint review meeting, the development team shows all features from the sprint to the product owner. The product owner decides if they meet the acceptance criteria. The sprint review meeting is open to all stakeholders, CEOs, everybody who is interested. The highlight is the live demo of every feature. When a card is nearly done or rejected it gets back to the product backlog. Here’s the agenda:
- Product demonstration
- Product owner declares what’s done
- [Measure velocity]
- Stakeholder feedback
About sprint review meeting: http://scrumtrainingseries.com/SprintReviewMeeting/SprintReviewMeeting.htm
Sprint retrospective meeting
Whereas the sprint review meeting is to inspect and adapt the product, the retrospective is to inspect and adapt the process. It’s the change of the team to improve the process.
It is very important to create a safe room where this discussion can happen. That is why no one outside of the scrum team except for the scrum master attends. A suggested agenda is:
- What went well, as positive
- What went not so well, as negative
Everybody participating the meeting can bring up points that are written to the whiteboard either on the positive or the negative side. At the end of the meeting the team has to decide and commit for action items that they want to change in the next sprint.
The video is a great inspiration to the retrospective: http://scrumtrainingseries.com/SprintRetrospectiveMeeting/SprintRetrospectiveMeeting.htm
Backlog refinement meeting
In this meeting, the product owner and the team take a small look into the future. The goal is to break epics into small story cards that are
Each story cards should contain, the who, the what and the why. For example “As a user I want the button to be bigger so that I don’t miss it so often with the mouse”.
This video contains everything you should know about the backlog refinment meeting: http://scrumtrainingseries.com/BacklogRefinementMeeting/BacklogRefinementMeeting.htm
SCRUM is just a framework for organizing your development. It’s really useful to get things done, especially in a fast pace environment. But never forget that this will not solve underlying problems you have in your organization.
A big thank you to Michael James for the great videos. I can only recommend watching them or even better: hire him!