Over the past year especially I have become a real advocate of approaching my web development tasks in an agile way. Historically I would gain a brief, write a spec, create wireframes, create design compositions in a software program such as Illustrator or Photoshop, create a html prototype, create a functional spec on the server side requirements of that prototype, hand over to a server side developer etc. etc. It was as you can imagine quite a heavy-duty, time consuming way of working which in most cases also resulted in wasted time as once the design translated into the working prototype, nine times out of ten we’d have to go back to the drawing board and revisit something that we had overlooked in the planning phase.
The way I like to work now is that I try to produce a working prototype as soon as possible, it’s often not polished and designed well, nor does it have all of the answers in terms of functionality but I find that once there’s something to work with and that I can put in-front of project sponsors we can swiftly get on with the development and launch a project is a much better and time efficient way.
Agile development:
- Encourages team communication and self-organisation
- Measures success by delivering value with working software
- Integrates the voice of the customer into the development process
- Responds to changing requirements
Scrum is…
An agile model consisting of a well-defined framework for carrying out software development in a series of iterations working as a team.
The Scrum Team
- Stakeholder is someone outside the Scrum team who has a say in what the product should be, such as a manager, client, or customer.
- Product Owner is the “voice of the customer” and is responsible for developing, maintaining, and prioritizing the items in the product backlog.
- Scrum Master is responsible for making sure the work of the team goes smoothly by facilitating Scrum and removing impediments.
- Development Team Members are the members of the team who write and test code.
A sprint is….
A basic unit of work (a single iteration) carried out by the scrum team, it’s also sometimes referred to as a timebox. A team may complete several sprints on its way to releasing a piece of software.
- Values working software over comprehensive documentation, most of the work happens within the sprint – details can be sparse.
- At the end of the sprint the software will have been designed, built and tested.
Starts with:
A team committing to work to be done, an agreed upon ‘definition of done’
Ends with:
A demonstration of potentially shippable content.
Generally the length is no longer than one month
- The team has agreed that the sprint can’t grow beyond the time limit – everyone is committed to completing the agreed work within the sprint
- Typically each sprint has the same time duration (candence)
- Allows the team to form a rhythm for their work, resulting in a predictable pattern for future sprint estimates
- A new sprint begins immediately after the previous sprint has been completed
Sprint Events
Sprint Planning
Within the sprint planning phase the whole team gathers to prepare for a new sprint. The product owner refers to the product backlog then presents a sprint goal/ theme to ensure the team stays on track during the sprint, the goal also serves as a reminder of the value being delivered. The team discusses overall solutions without going into detail of how the problem will be solved, drafts conditions of acceptance and agrees the length of the sprint.
Backlog Refinement
- The product owner reads through the PBI and goes through the user story
- Team members listen and ask clarifying questions to get a full understanding of the work that they are agreeing to estimate for effort
- The team come to the consensus of whether to bring the item into the sprint, there are techniques such as planning poker to help the team derive at a consensus.
- This is then moved from the product backlog into the sprint backlog
- The steps are repeated until the team decide they have reached capacity and can no longer accept anymore PBI into the sprint backlog
- The sprint backlog is then broken out into tasks which are designed to be picked up by individual team members
- These tasks should detailed all steps necessary and need to be in a format that could be tracked throughout the taskboard
Daily Stand Ups
Daily stand ups should last around 15 minutes (or less) and allow for team members check in and provide an update on their status, report any issues that are blocking them and update the task board.
Three questions are covered:
- What did you do yesterday?
- What do you plan to do today?
- What obstacles are slowing you down?
Team members all take shared responsibility to go through the meeting and meetings start on time without waiting for people. If two members require a conversation which are longer than the stand up and doesn’t require the whole team to be involved it is moved to the sidebar so that it is not forgotten and people can pick up after the meeting
Sprint Review
During the sprint review, which generally lasts half an hour or less, the potentially shippable sprint product is demonstrated to the stakeholders. The demo is measured against the user stories and the sprint goal and offers a platform where Stakeholders can ask questions and provide feedback of the direction that has been demonstrated. The product owner gathers feedback from the stakeholders.
Retrospective
The retrospective review goes through the sprint timeline and offers the team a chance to reflect on the work they have done, discuss how they did it, identify areas of improvement and set a measurable goal for the next sprint.
Questions Covered
- What went well?
- What could have gone better?
- What can we change?
Glossary
- Product backlog items (PBI) may include;
- defects and technical items
- user stories
- bug
- feature request
- large poorly defined items known as epics (which will need to be broken into smaller, more manageable items)
- Sidebar
- One on one/ smaller groups can break out and not occupy the whole teams time
- Teams have a recognised signal for redirecting the conversation to the sidebar in a polite way
- Definition of Done
- Tasks are complete
- Code is reviewed
- Item is tested
- Reviewed by stakeholder
- Product Owner reviews conditions of acceptance