Scrum is a well known — is it really well known? — agile methodology. It consist on building a project with small iterations on done work and periodic reporting of advances. It is widely used since you can track easily how the project is going and detect problems on early stages. It is not very linked to software modelling and design, instead it uses another kind of construction methods. You can use various kinds of iteration types, depending on how dynamically can you handle the requirements and how indecisive is the customer. You can use iterative, incremental and evolutionary types of iterations, from the greatest to the smallest one. Iterative and incremental handles requirements formally, and evolutionary is more like a kind of craftsmanship, requiring the customer to be very present on the development process.
Scrum requires three main roles, which are related to the development process rather than hierarchical structure. Those main roles have the intention to consolidate a strong iterative development process, and you can define them as follows.
- Scrum Master
- His role is similar to a project manager, is who maintains the Scrum process. So, he is controlling and directing the project through the Scrum process, making the project to advance on its milestones.
- Product Owner
- He is like the software analyst and who represents the business and stakeholders. He handles the high level and functional requirements, transmitting them to the Scrum Master.
- Team
- Is the development team, including the QA team, the people who make the things work. Everyone that construct, test and release the product.
We can find three well defined stages on the process, project definition, sprint running and project release. On the project definition stage, we define the entire project with very high level and functional requirements, we start with an initial estimate that can be varying according to the requirement changes — which makes the project cost to vary according to new milestones — and when we get the customer agreement to build the project. On the sprint running stage, we are building the product, so the customer iterates through sprints approving the constructed modules or components of the software. Finally, on the project release stage we setup a release process with final QA stages and customer approval.
On the project definition stage we must define the initial estimate and the project scope, so we can track it, also we can define the project sprints, which modules will be handled. It is not required that sprints have fixed periods of time, instead you can setup the sprints according to project components and modules, allowing the completion of milestones that can be shown to the customer to allow you to have early feedback on each component. Each sprint consist of set of work breakdown structures to meet the customer requirements or a fixed period where some goals regarding the WBS should be meet consistently. The WBS that I use on my projects is that one that I can handle using my sprint planning tool, a simple spreadsheet that allows me to assign story points to user stories, and create estimates according the required artefacts to be constructed to meet the user story, you can find the spreadsheet on my article Scrum.org. 2009. Retrieved 2010-04-03.“A Tool for Sprint Planning”.
Each sprint consists on three kinds of meetings: sprint planning, stand-up meeting and sprint retrospective. On the sprint planning meeting you setup the WBS to work on, also you get the feedback about the required tasks to be completed during the sprint, the user stories that should be meet and how do you will handle the development process during the sprint. The stand-up meeting is daily meeting where you get the status of the development process, and where you ask three basic questions to developers: “what have you done yesterday?”, “what will be your work for today?” and “do you have any obstacle to complete your tasks for today?”. The sprint retrospective is meeting is made with the intention to enhance the development process, how the developers should handle the feedback and how the Scrum Master and Product Owner should handle the completed tasks, simply asking “how can we do a better work?”.
On this process you have three main artefacts, where the product backlog holds the product features and highest level requirements, and it can be represented mainly by user stories or use case level requirements. The sprint backlog is where do we get the WBS for each sprint and the feedback that we obtain from the sprint retrospective meetings, and the burn down is a report where we can appreciate how is going the project, with some well known charts like the business value chart and the burn down chart.
The release processes must be defined by you. Usually the minimal requirements for a release is that the project is passing all unit tests, the QA team has approved the product and you can meet almost all requirements taken from the customer. So, you must remember to include enough time to let the development team to construct unit tests and related stuff, including debugging and hardening time, to allow the release of a product with high quality standards.
You can use various tools to track your project. Pivotal Tracker, Atlassian Jira or Scrummy, among a wide variety of software tools that can help you in your project. Or you can keep your old style of using post-it notes in a scrum panel, which is valid too, but not ordered for me. Enjoy using Scrum as your development process methodology.
further reading
- Sutherland, Jeff (2004-10). “Agile Development: Lessons learned from the first Scrum”.
- Gauthier, Alexandre (August 17th, 2011). “Agile Vocabulary & Artifacts”.
- Dubakov, Michael (2008). “Agile Tools. The Good, the Bad and the Ugly.”.
- Scrum.org. 2009. Retrieved 2010-04-03. “The Scrum Guide”.
Entries 