-
Notifications
You must be signed in to change notification settings - Fork 16
Workflow Processes
This document describe the workflow processes used to assign and complete work on the PlanetLab project. We try to keep these processes light-weight and agile.
User stories are used to describe desired features of the product. They are non-technical documents which are intelligible to both product owners and developers. Their purpose is to describe the total product in a series of small stories which are mutually intelligible by technical and non-technical team members who can negotiate their content. User stories are written in the form: "As a <type of user>, I need to <do X> so that I can <accomplish Y>."
Examples:
- As a learner, I need to search through missions so I can find those that interest me.
- As a mentor, I need to see learners' work submitted on their missions so that I can evaluate their work.
The product owners are responsible for maintaining the user stories, but they should be written with input from the development team. Meetings are held to write new user stories as necessary. The collection of user stories is currently available here. The development team is responsible for distilling each user story into a set of concrete engineering tasks before beginning work on that user story.
Stand-ups occur at the beginning of the day before work begins. The people who will be doing development work are required to attend. Other interested parties are allowed to listen in to the meeting, but the purpose of stand-up is for the team members working on the sprint that day to self-organize.
A standup featuring developers Achilles and the Tortoise would look like this:
Achilles: Yesterday, I did X. Today, I will do Y. I am ready to go on Y today — no blockers.
Tortoise: Yesterday, I did X. Today, I will do Y. However, I have a question about A that I need answered before I can start on Y today.
Achilles: I can answer A; let’s talk about it after standup.
Tortoise: Super.
Stand-up allows the people who will be working on sprint items that day to self-organize and ensure they are working on what they all agree are the right things (no one is duplicating each other’s work or doing off-sprint tasks) and that they are prepared to start working.
Sprint reviews are held at the completion of each sprint. They allow the team to show the user stories they completed during to sprint to the project's stake-holders. The stake-holders are responsible for confirming user stories as complete after they are demoed by the team.
A sprint review meeting with developers Tortoise and Achilles, stakeholder Red Queen, and technical lead Turing:
Tortoise: Our team completed user stories Y and Z this sprint.
Achilles: I will now demo user story Y for the audience.
Queen of Hearts: LOVELY — we affirm user story Y as complete.
Tortoise: I will now demo user story Z
Queen of Hearts: I was expecting the demo of a completed user story Z to contain A!!!
Tortoise: I believe we did not consider A...
Queen of Hearts: OFF WITH THEIR HEADS!!!
Achilles: Can we just move user story Z into the next sprint, instead?
Queen of Hearts: ACCEPTABLE.
Tortoise: We had planned to complete user story X this sprint, but we were unable to because of B.
Queen of Hearts: OFF WITH THEIR HEADS!!!
Turing: Actually, let’s talk about B during sprint planning — I have an idea to make this easier.
Sprint reviews determine what was completed last sprint and allow product owners to check the sprint's work against the long-term goals of the product.
Sprint planning is held after the sprint demo and determines which users stories the development teal will attempt to complete in the next sprint. The product stake-holders determine which user stories are the most important to accomplish next, and the development team estimates how many of the desired user stories can be completed in the sprint.
The development team estimates the 'Fibonacci complexity' of a user story. They take a user story and together assign it a Fibonacci number (1, 2, 3, 5, 8, 13...) representing its complexity and difficulty to implement. Thus, at the end of a sprint, the team will be able to determine how many Fibonacci units of complexity they are able to accomplish. This establishes a velocity (the team is perhaps able to complete 10 Fibonacci units of complexity a week) which can be used to estimate how much work they can accomplish next sprint.
A sprint review meeting with developers Tortoise and Achilles, stakeholder Red Queen, and technical lead Turing:
Tortoise: We stil have work to do on user Story X, which we had hoped to finish last sprint but did not
Achilles: What are the most important user stories for us to work on this sprint, in addition to X, Queen of Hearts?
Queen of Hearts: User stories Y and Z
Tortoise: Very well, let us estimate user stories Y and Z
Tortoise and Achilles estimate the fibonacci complexity of user stories Y and Z
Achilles: According to our sprint velocity, we only have enough time to do user story X and either user story Y or Z
Queen of Hearts: OFF WITH THEIR HEADS — err, do user story Y, then
Tortoise: Very well, we will finish user stories X and Y this sprint.
Turing: We will now build out a list of the engineering tasks which will accomplish user stories X and Y. You are free to leave, Queen of Hearts.
Achilles, the Tortoise and Turing write out a list of engineering tasks which will lead to the accomplishment of user stories X and Y. They will divvy up these tasks during the sprint’s stand-ups as they finish each one.
Sprint planning determines what needs to be completed and how it will be completed next sprint. Input on the sprint from product owners should only come during sprint planning, which allows the developers to work unimpeded on pre-determined tasks.