How to do it wrong?
The past decades have shown that the conservative way of doing software development, called "The Waterfall Model" just didn't work out well, because requirements cannot be defined from the very beginning.
A lot of requirements become more clear to the client when other features are already implemented. The result is that a lot of work that has been invested in requirement engineering and design will need to be discarded and hence a lot of money that has been spent on it will be lost. Also technical difficulties on the way cannot be predicted and sometimes features would need to be adjusted because of that. Also the stakeholders will only have a working product by the end of this cycle, which would be usually after a couple of months. If something goes wrong on the way, and the budget is hit, there would be no working product and hence no value for the client.
This model is obsolete and modern development shops work with an agile process that is more responsive to changes and makes sure that a working product is shipped regularly. A very common agile process, which we also implement at Suria Labs, is Scrum.
What is Scrum?
Scrum is an agile process that breaks down the development process into multiple iterations, called Sprint. Each Sprint includes the traditional steps and are a closed unit, which means that the outcome of a Sprint is a shippable product, which is feature complete but has a value for the client and helps him to visualise the next steps. Sprints at Suria Labs last for one week.
The product backlog
However, this does not mean that no specification is necessary at all. Before kicking off with the development, the vision for the product need to be clear and specified in so called user stories. Each user story describes a feature from the perspective of a user.
These user stories don't need to be more specific, they will be specified in detail at the beginning of each Sprint in the so-called Sprint Planning. Visuals such as process charts and mock-ups for key components can also help to understand the vision of the project. Again, this is not meant to be a detailed specification, because this would not be agile and lead back to the waterfall model described in the first chapter.
The sum of all user stories define the Product Backlog which is the basis for all ongoing development. At Suria Labs we use Trello to manage the product backlog.
Each story in the product backlog is estimated, however since we have no further detail of the story, we estimate it by its complexity. A story is considered complex when its specification is very broad, e.g.
What is meant with "rating" is not further specified and can mean anything, from giving a musician a simple "like", via a 5-star rating up to a complex survey. Hence the time effort for implementing this story can probably be anything from 2-20 hours. If we hit such a big time range a story is considered as complex. A less complex story would be probably:
This doesn't leave much room for interpretation. We have seen that many times on other websites. There will probably a form somewhere where a user can enter his email address and click a "Subscribe" button. The complexity is hence very low. The measure for this complexity is called Story Points. You will find the estimated story points in parenthesis on each user story in your Trello board.
Ready for kick off?
We now have our estimated product backlog and some visuals. So let's start with our first sprint which begins with a Sprint Planning. There a three major roles in Scrum. The product owner, the scrum master and the team. The product owner carries the vision for the project and the decision from all stakeholders and should be ideally one single person. The scrum master is part of the team and makes sure that the process is on track and removes communication impediments. The team consists of the developers and the designers.
During the sprint planning all three parties get together and decide on the sprint goal, which is are the user stories that the team should work on during the sprint. This planning can be either a physical meeting or be held via Google Hangout. The stories for the sprint goal will be the ones on top of the prioritised product backlog and be usually discussed internally before the meeting amongst the stakeholders.
During the planning they will be detailed. For example:
- There should be a link for signing up on the landing page
- The user needs to specify his
- First name
- Last name
- Password confirmation
- After the sign up the user should be redirected back to the landing page
- There should be a message: "You have successfully signed up"
- The user should receive a confirmation email
- If the user confirms his account, he will be able to sign in
These are the detailed information the designer needs for doing the mockups and design and the developers need for starting with the implementation. They are also called Acceptance Criteria. The product owner will be also consulted during this specification if there are any impediments or the developers see better or easier ways given their technical expertise.
That's it, we have defined our Sprint Backlog. we are ready to start. See you at the end of the week for the Sprint Review.
The sprint review
For the sprint review all Scrum participants come together again. The team has deployed a running version to a staging environment before already. The product owner can invite other stakeholders for this meeting. We will share our screens and make a walk-through for each implemented story from the sprint backlog. We will check together whether all the acceptance criteria have been met. The product owner can make comments about the current product here. This can either lead into a new story or an adjustment for a reviewed story. After the review the stake holders will be able to start using the app already even though it won't be feature complete yet.
REViewing the progress
The achieved story points for the sprint will be tracked in a Sprint Burndown Chart. The project goal is reached when the product backlog is empty, hence no more story points left, for instance if the budget lasts for 10 sprints, and there is a total of 200 story points in the backlog, the goal for each sprint should be to get stories with a total of 20 story points done.
Slow progress can happen though and might lead back to changing requirements or technical difficulties during the development. There are couple of things that can be done here:
If the budget is about to be reached, it might make sense to deprioritize stories that are not important for an MVP and postpone their implementation for the future when more funding is raised.
If a deadline is about to be reached, it might make sense to get more developers on board, so that more story points can be achieved during the week.