In the previous article we covered the introduction to agile. In the following minutes you will learn about the processes involved in planning and executing a typical agile project.
How to plan a scrum
Instead of following the more traditional process of writing lengthy requirements or specifications, agile takes a lightweight approach of writing down brief descriptions of the pieces and parts that are needed. These become work items and are captured in the form of user stories. A user story is a simple description of a product requirement in terms of what that requirement must accomplish for whom.
Unlike other developers, agile team members estimate in something called points. Points represent a size-based, complexity-based approach to estimation. Small and simple tasks are one point tasks, slightly larger/more complex tasks are two point tasks, and so on. Points are kind of like t-shirt sizes. There are small, medium, large, extra large, and potentially other sizes (extra small and extra extra-large). These sizes are relative — no regulation dictates how much larger medium is compared to small.
As you refine your requirements, you need to refine your estimates as well. Planning Poker is a technique to determine user story size and to build consensus with the development team members.
The numbers on the cards are usually from the Fibonacci sequence. The reason why the points are in a Fibonacci sequence is to help estimate better. An Eight story is larger than a Five and lesser than a Thirteen but not precisely related – for example it’s not double or half of another estimate. It’s relative.
So how to play this is that the development team sits in a circle and goes through all the user stories one by one. The team decides on a point which they think should be the weight of the story and reveal their points at the same time to each other. If there’s a huge gap in points for example someone estimated 13 and another 2, then they both discuss and a lot of misconceptions are removed this way. The average consensus is then finalized as the story’s point.
Iteration Review Meeting
The iteration review, or sprint review in Scrum, is a meeting to review and demonstrate the user stories that the development team completed during the iteration to the stakeholders. The stakeholders get a chance to see progress on the product and provide feedback.
Iteration Retrospective Meeting
After the iteration review is over, the iteration retrospective begins. The iteration retrospective is a meeting where the team lead, the product owner, and the development team discuss how the iteration went and what they can do to improve the next iteration. The goal of the meeting is to continuously improve your processes.
Hope this was an informative and fun way for you to get introduced to Agile. Do share with us your feelings and thoughts.