Burn Down Charts
Sprint Back Log
Product Back Log
Scrum is based on small teams. It enhances communication between team members. Nevertheless, there is a huge amount of software that is developed by solo programmers. A software system being built by a single programmer can still benefit from some of the Scrum principles such as: a product backlog, a sprint backlog, a sprint and a sprint retrospective. Solo Scrum is an adapted version of Scrum for use by solo programmers.
Each day during the sprint, a project status meeting is arranged. This is called a scrum. The scrum has specific guidelines: The meeting starts precisely on time with team-decided punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken around your neck) All are welcome, but only "pigs" may speak The meeting is timeboxed at 15 minutes regardless of the team's size All attendees should stand The meeting should happen at the same location and same time every day During the meeting, each team member answers three questions: What have you done since yesterday? What are you planning to do by tomorrow? Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to remember these impediments.) After each sprint a brief sprint retrospective is held, at which all team members reflect about the past sprint. The purpose of the retrospective is to make continuous process improvement. This meeting is timeboxed at four hours. Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that fundamentally empirical challenges cannot be addressed successfully in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach – accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.
Scrum is a process skeleton that includes a set of practices and predefined roles. The main roles in scrum are the ScrumMaster who maintains the processes and works similar to a project manager, the Product Owner who represents the stakeholders and the Team which includes the developers. During each sprint, a 15-30 day period (length decided by the team), the team creates an increment of shippable software. The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done. What backlog items go into the sprint is determined during the sprint planning meeting. During this meeting the Product Owner informs the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint. During the sprint, the team completes the fixed set of items called backlog items. During the sprint no one is able to change the backlog, which means that the requirements are frozen for sprint.
The following terminology is used in Scrum Burn Down Chart: Daily progress for a sprint over the sprint's length. Product Backlog: A prioritized list of high level requirements. Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders. ScrumMaster: The person responsible for the Scrum process, making sure it is used correctly and maximizes it benefits. Sprint: A time period (usually 2 to 4 weeks) in which development occurs on a set of backlog items that the Team has committed to. Sprint Backlog: A list of tasks to be completed during the sprint. Team: A cross-functional group of people responsible for managing itself to develop the product.
Following are some general practices of Scrum: Customers become a part of the development team. (i.e. the customer must be genuinely interested in the output.) Like all other forms of agile software processes, Scrum has frequent intermediate deliveries with working functionality. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs. Frequent risk and mitigation plans developed by the development team itself. – Risk Mitigation, Monitoring and Management (risk analysis) at every stage and with genuinity. Transparency in planning and module development – Let everyone know who is accountable for what and by when. Frequent stakeholder meetings to monitor progress – Balanced (Delivery, Customer, Employee, Process) Dashboard updates – Stakeholders' update – You have to have Advance Warning Mechanism, i.e. visibility to potential slippage / deviation ahead of time. No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem. Workplaces and working hours must be energized. – "Working more hours" does not necessarily mean "producing more output."