This Guide aims to introduce you to the way we get "stuff" done (e.g. work) at Life Itself. As we work mostly self-organized and independent, it is important to understand some of the key tools and processes that we use.
We use a scrum-based agile process for delivering projects. This process can be used for both technical and non-technical projects1.
If you have not yet been onboarded, please check the Onboarding Guide to get set up first.
Working at Life Itself is different from traditional working environments. Teams at Life Itself are self-organising. We trust each other to get our work done, and we have the freedom to do it our own way (within reason). Read Working With Us to find out more about our culture and what makes us unique.
Finally, we believe in Getting Things Done.
Work is organized in short cycles called sprints. Each sprint cycle is initiated by a sprint meeting, where team members review the past sprint and set new goals and tasks for the upcoming sprint. See the Sprint Process below to find out more.
Most importantly:
- Tasks are agreed on in the sprint planning meeting on a Wednesday -- the sprint then runs for 2 weeks.
- Tasks should be in the product backlog.
These are largely based on standard scrum process see e.g. Wikipedia http://en.wikipedia.org/wiki/Scrum_(software_development)
The Project Owner's primary task is the creation and prioritization of job or user stories. Specifically, the Project Owner:
- writes (or has the team write) customer-centric items typically user stories or, preferably, job stories
- assigns "business" value to them
- prioritizes (ranks) them
- and adds them to the product backlog
At Life Itself, the roles of the project owner and delivery team are often merged, meaning that individual team members may work independently on a project and write the job stories themselves.
Delivery is facilitated by a Scrum Master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. The Scrum Master is not a traditional team lead or project manager, but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the process is used as intended. The Scrum Master is the enforcer of the rules of process, often chairs key meetings, and challenges the team to improve. The role has also been referred to as a servant-leader to reinforce these dual perspectives.
Responsible for accomplishing all goals at the end of each Sprint (the Sprint Goals). The Delivery Team is self-organizing, even though there may be some level of interface with other parts of the organization.
Before project kick-off there is some preparatory work that should be done. Total time required should be no more than a day. However, for larger projects this may take longer. The Project Owner is overall responsible for this stage of the process.
Preparation usually includes the creation of a Project A10 and key job stories, as well as ongoing documentation in the Project DB. These will be explained in more detail below.
Project Owner [1h]
The Project A10 serves as a a Project Overview document. It is intended to document the project throughout its proposal, initiation, and completion stages.
This is our A10 template.
Before the project is initiated, the project owner should note:
- Key expected outcomes
- Ressourcing estimates
- Team members involved
- Total Budget
- Aims and Requirements (Purpose, Outcomes and Outputs)
- Project Plan
- Issue tracker
- Risks
These may be continuously updated during the project.
Finally, once a project has been completed, a retrospective should be done that includes key learnings gained from the project process.
Please note, while creating an A10 is highly encouraged, short tasks may be included in the sprint cycle whithout requiring the creation of an A10.
Project Owner + other relevant personnel [2-6h]
The Project Owner, together with other relevant team members, is responsible for generating a first set of user stories for a project.
User stories are generated to gather project-specific requirements. Please read here to learn more about user stories.
In general, user stories:
-
Do not need to be comprehensive -- you can add more user stories later. However, it is good to have written the core user stories down, and enough to cover, what (at this point), one would anticipate to be at least first 2-3 sprint iterations.
-
Will have a transformative effect on the quality of the project. We cannot over-state the value of generating (good) user stories at this point.
-
Should involve some or all of delivery team + scrum master, for at least some part of this, because:
- Gets everyone up to speed
- Rubber-duck test (have to explain and walk through user stories with others which helps clarify them)
At Life Itself, we move from user stories to job stories. Job stories give the team more context for the user’s situation and allow them to share their viewpoint and create a solution for what the user wants to do. Job stories are very similar to user stories with one key difference: personas becomes contexts (and jobs).
Read more about Job Stories.
Project Owner + other relevant personnel [1-2h]
- An SCQH is best created in a small group of people, say maximum 7-8 (but you can do more) and then shared outwards.
- Allow at least 2h to create an SCQH.
- It will be faster the smaller the group and the more experience people have with the process.
SCQH is a problem solving tool that can be used in a number of ways, from telling stories to structuring research programmes to planning projects.
- SCQH stands for Situation, Complication, Question and Hypothesis.
- It is sometimes written as SCQA, for Answer, but it is usually helpful to treat the last component as a Hypothesis, which can then be tested.
- It describes a problem (situation, complication) frames a question about what to do, and finally offers a solution in the form of the hypothesis.
- The hypothesis is optional. In some cases, you will only have a question at the start of your work and a hypothesis will only come later (once you’ve done work on your question).
- An SCQH does two things: provides clarity on the problem (and solution) and aligns the group on that.
- The SCQH is an important group alignment process.
We use GitHub Issues to track our work. Read our guide on how we use Issues.
The key principles of the agile approach to delivery are2:
- Organize work in short cycles called sprints [2(-4) weeks]
- The management does not interrupt the team during a work cycle
- The team meets so that each team member can share their progress.
- Team = delivery team + scrum master
- The team estimates how much time work will take
- The team decides how much work it can do in an iteration
- The team decides how to do the work in the iteration
- The team measures its own performance
- The team defines work goals before each cycle starts
- The team defines work goals (primarily) through job stories
Every two weeks we hold a Sprint Meeting that consists of a Sprint Review and Retrospective of the last sprint and the Sprint Planning of the upcoming sprint. The meeting should usually be no longer than 2 hours.
We created a sprint meeting template that summarizes the structure of the meeting.
What did we ship this sprint? See http://www.mountaingoatsoftware.com/agile/scrum/sprint-review-meeting
During the sprint review, the projects are assessed against the sprint goal determined during the last sprint planning meeting. Ideally, the team has completed each product backlog item brought into the sprint, but it’s more important that they achieve the overall goal of the sprint.
- Usually no more than 40 minutes.
- Team shows what they accomplished during the sprint.
- Any blockers are identified and discussed.
- Key learnings are captured.
- Kept very informal. A sprint review meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the sprint.
What can we learn from this sprint for the future? See http://www.mountaingoatsoftware.com/agile/scrum/sprint-retrospective
- Kept even shorter.
- Start-Stop-Continue structure (what should team start doing, stop doing, and continue doing)
-
Meeting is timeboxed to 1-1.5h.
-
Team members create promises and goals for this sprint that are reviewed by the team.
-
Team members create new issues and review the sprint board together.
-
This meeting results in 2 outputs:
- A sprint goal for each project – a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner.
- A sprint backlog -- A sprint backlog is a list of the product backlog items that the team commits to delivering plus the list of tasks necessary to delivering those product backlog items.
- Individual Tasks should be less than 2d total time (reduces estimation error).
Each sprint has a sprint backlog -- a list of the product backlog items that the team commits to delivering plus the list of tasks necessary to delivering those product backlog items.
See http://www.mountaingoatsoftware.com/agile/scrum/product-backlog
-
Product backlog consists of user stories and tasks related to user stories (should flag which user story a task relates to if not a single user story)
-
Tasks are broken into at least 2 groups:
- Prioritized (tasks in priority order).
- Unprioritized: storage place for all tasks that people have thought up but have not yet been prioritized (and are usually implicitly of lower priority than currently prioritized tasks).
- Tasks should contain short descriptions
- It's not necessary to start a project with a lengthy, upfront effort to document all requirements
Milestones
- Sprints are organised via Milestones. Naming convention:
Sprint - DD MMM YYYYwith the date being the last day of the sprint. - Issues scheduled for future sprints are allocated to the relevant milestone.
- Icebox - catch all milestones for issues that are "someday maybe" type of things (not likely to be worked on the near-term)
Labels
- ‘Prioritized Backlog’ - issues that have been reviewed and prioritised but have not been allocated yet.
- ‘In Progress’ - issues currently worked.
- ‘Blocked/Waiting For’ - if there is a blocker.
- ‘In Review’ - issue is reviewed and/or has to be signed off. Once signed off, the issue needs to be closed.
- ‘Wontfix’, ‘Duplicate’, ‘Invalid’ - closed issue without being delivered, e.g. circumstances have changed, a duplicate issue has emerged which provides the desired outcome or the issue isn’t valid anymore. Note: add a short comment specifying the reason why the issue hasn’t been delivered.
See http://www.mountaingoatsoftware.com/agile/scrum/daily-scrum and http://en.wikipedia.org/wiki/Stand-up_meeting
-
Daily team meeting
-
Purpose: keep team in sync; identify surface blockers
-
Each person answers 3 questions:
- What did I accomplish in the last 24h?
- What will I accomplish in the next 24h?
- What obstacles are impeding my progress?
-
The meeting is strictly timeboxed to 5-15m
- Answers should be very short -- each person should speak for no more than 2 minutes (less as the team gets larger).
- If bigger issues arise, take them out of standup.
From this answer
The Project Owner and a Project Manager are quite different.
On a traditional project, a Project Manager, as the title implies, manages a project.
However, on a Scrum project, the Development Team manages their own work.
Individual team members can be Project Owners and therefore be responsible for maximizing the value of the project and the work of the Development Team. They are the sole person responsible for managing the Project Backlog.
At Life Itself, individual team members sometimes work alone on projects, thereby fulfilling the role of the project owner and development team at the same time.
Product Backlog Management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Ensuring the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
Footnotes
-
Whilst Scrum (and Agile generally) was originally developed for software projects, it has now successfully been used for many non-software projects. ↩
-
Adapted from http://www.forbes.com/sites/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/ ↩