Escolar Documentos
Profissional Documentos
Cultura Documentos
3 21
Burndown Charts
Burndown charts show work remaining over time. Work remaining is the Y axis and time is the X axis. The work remaining should jig up and down and eventually trend downward. The Scrum books define a sprint burndown chart as a place to see daily progress, and a product burndown chart as where to show monthly (per sprint) progress.
Back to Top
1. 2. 3.
"What have I done since the last Scrum meeting? (i.e. yesterday)" "What will I do before the next Scrum meeting? (i.e. today)" "What prevents me from performing my work as efficiently as possible?"
The ScrumMaster ensures that participants call sidebar meetings for any discussions that go too far outside these constraints. The Scrum literature recommends that this meeting take place first thing in the morning, as soon as all team members arrive.
Back to Top
Impediments
Anything that prevents a team member from performing work as efficiently as possible is an impediment. Each team member has an opportunity to announce impediments during the daily Scrum meeting. The ScrumMaster is charged with ensuring impediments get resolved. ScrumMasters often arrange sidebar meetings when impediments cannot be resolved on the spot in the daily Scrum meeting.
Back to Top
Product Backlog
The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and nonfunctional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product backlog, it is the sole responsibility of the product owner to prioritize the product backlog. During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner's priorities.
Back to Top
Some Scrum practitioners estimate the effort of product backlog items in ideal engineering days, but many people prefer less concrete-sounding backlog effort estimation units. Alternative units might include story points, function points, or "tshirt sizes" (1 for small, 2 for medium, etc.). The advantage of vaguer units is they're explicit about the distinction that product backlog item effort estimates are not estimates of duration. Also, estimates at this level are rough guesses that should never be confused with actual working hours. Notethat sprint tasksare distinctfromproductbacklogitems and task effort remaining is always estimated in hours.
Back to Top
For more on product and release burndown charts, please see: http://www.mountaingoatsoftware.com/release_burndown
Back to Top
Release
The transition of an increment of potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more sprints has resulted in the product having enough value to outweigh the cost to deploy it. "The product is released to customer or marketplace obligations. The release balances functionality, cost, and quality requirements against date commitments." (Schwaber/Beedle,Agile Software Development with Scrum, p. 80).
Back to Top
Scrum Roles
ScrumMaster Role
The ScrumMaster is a facilitator for the team and product owner. Rather than manage the team, the ScrumMaster works to assist both the team and product owner in the following ways:
Remove the barriers between the development and the product owner so that the product owner directly drives development. Teach the product owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum. Improve the lives of the development team by facilitating creativity and empowerment. Improve the productivity of the development team in any way possible. Improve the engineering practices and tools so that each increment of functionality is potentially shippable. Keep information about the team's progress up to date and visible to all parties.
Sprint
An iteration of work during which an increment of product functionality is implemented. By the book, an iteration lasts 30 days. This is longer than in other agile methods to take into account the fact that a functional increment of product must be produced each sprint. The sprint starts with a one-day sprint planning meeting. Many daily Scrum meetings occur during the sprint (one per day). At the end of the sprint we have a sprint review meeting, followed by a sprint retrospective meeting. During the sprint, the team must not be interrupted with additional requests. Guaranteeing the team won't be interrupted allows it to make real commitments it can be expected to keep. Out of practical necessity, some teams choose to bend this rule by declaring some team members 80 percent available at the outset so they still have some cycles left for "Priority One" bugs and emergencies. But this is a slippery slope and should be avoided whenever possible.
Back to Top
Sprint Backlog
Defines the work for a sprint, represented by the set of tasks that must be completed to realize the sprint's goals, and selected set of product backlog items.
Back to Top
Back to Top
Sprint Goals
Sprint goals are the result of a negotiation between the product owner and the development team.
Meaningful goals are specific and measurable. Instead of "Improve scalability" try "Handle five times as many users as version 0.8." Scrum focuses on goals that result in demonstrable product. The product owner is entitled to expect demonstrable product (however small or flimsy) starting with the very first Sprint. In iterative development, subsequent Sprints can increase the robustness or size of the feature set. Have your team commit to goals that anyone will be able to see are met (or not met) at the end of the sprint. At sprint review meetings, the sprint demonstration is conducted after which the team asks the product owner whether (s)he feels the goals were met. While some specific product backlog items may not be done at the end of a sprint, it should be very unusual for a team not to meet its sprint goals. Scrum requires the team to notify the product owner as soon as it becomes aware it will not meet its goals.
Back to Top
The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The team and ScrumMaster meet to discuss what went well and what to improve in the next sprint. The product owner does not attend this meeting. The sprint retrospective should be time-boxed to three hours. Kelley Louie (Certified Scrum Practitioner) writes: "The sprint retrospective meeting is an integral part of the inspect and adapt process. Otherwise, the team will never be able to improve their overall output and not focus on the overall team performance. The ScrumMaster must pay attention to this meeting and work towards resolving the impediments that may be slowing down the team."
Back to Top
Sprint Task
In Scrum, a sprint task (or task) is a unit of work generally between four and sixteen hours. Team members volunteer for tasks. They update the estimated number of hours remaining on a daily basis, influencing the sprint burndown chart. Tasks are contained by backlog items. Scrum literature encourages splitting a task into several if the estimate exceeds twelve hours.
Back to Top
Team
A team (or "Scrum team") is optimally comprised of seven plus or minus two people. For software development projects, the team members are usually a mix of software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. This is often called "cross-functional project teams". Agile practices also encourage cross-functional team members. During a sprint, the team self-organizes to meet the sprint goals. The team has autonomy to choose how to best meet the goals, and is held responsible for them. The ScrumMaster acts as a guardian to ensure that the team is insulated from the product owner. Scrum also advocates putting the entire team in one team room.
Back to Top
Team Member
In Scrum parlance, a team member is defined as anyone working on sprint tasks toward the sprint goal.
Back to Top
Velocity
In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning. Once established, velocity can be used to plan projects and forecast release and product completion dates. How can velocity computations be meaningful when backlog item estimates are intentionally rough? The law of large numbers tends to average out the roughness of the estimates. Back to Top Share on LinkedIn Share on Twitter
Article Comments
1. 2.
Unknown anonymous said on 15 May 07 09:41:
Thanks for this great resource! There are a few broken links on the page that need to be fixed.
Rebecca T. Traeger said on 15 May 07 14:19:
Thanks for the comments. You're right, there were some problems with this article. The broken links are a result of the move from the old website to the new website. The editorial team is working to fix these.
3.
Difficult to deliver large comprehensive tasks. The 30 day delivery often requires partial implemenrtations that require significant refactoring at the beginning of next sprint. The race is won by strategy, steady pace, and a spring at the end. Not sprinting the whole way.
4. 5.
We have found that 2 week sprints work better for us as we can fit 2 weeks into our heads but 1 month is hard to think about.
Chris Markiewicz said on 08 Oct 07 12:07:
I would like to thank you for the resource as well. I find it important to review the finer points from time to time as they seem to get lost after a while. By the way we utilizing 3 week sprints... 2 weeks were just not enough and we felt that 4 weeks
would be too much. For us the idea was to pick enough work that everyone could understand and keep focus on for the duration of the sprint.
6.
Nice resource. A suggestion for this site would be to have a 'collaborative glossary', where people can provide and refine definitions and others can vote on them. Not quite a wiki, more like www.urbandictionary.com
7.
I agree, this is a great resource. I use this list often. The only definition I found missing was one for the sprint review meeting. Is that something you could add? Thanks.
8.
On Sprint Task: "update the estimated number of hours remaining on a daily basis, influencing the sprint burndown chart." Should probably be: "update sprint burndown chart when a task is finished." Otherwise you're following time spent rather than work completed. Latter seems wiser.
9.
Kalle, I think it's critical to update the task estimates daily. Otherwise the team won't be able to see continuous progress or impediments of the tasks. Even a one hour task might change to an eight hour task (or multiple tasks..) due to new information found out during that one hour that was the original estimate. The key point is not to focus on how many hours the team got done on the task, but how many hours really are remaining. The daily update should never be: "I worked on that for four hours, so you can take four hours out of the estimate", but rather a real estimate on how much work still needs to be done based on current knowledge.
10. 11.
On Sprint Task: Kalle's view is correct, but only if the burndown is expressed in story points.
Abhijeet Selukar said on 19 Mar 09 12:16:
Useful! Couple of quick suggestions; one is to remove the link for Sprint Retrospective Meeting (http://wiki.scrums.org/index.cgi?ScrumScoreboard) which is not working anymore. And add Sprint Review in the gloassary.
Ehh, this link -- http://wiki.scrums.org/index.cgi?ScrumScoreboard -- is still not working (leads to domain for sale) :(
Nirmaljeet Malhotra (PMP, CSM, CSP) said on 03 Jan 10 23:05:
Some information about the Sprint Review meeting will be helpful. Thanks
Rostyslav Seniv said on 12 Jan 10 11:08:
I think The Team should be separated from The Scrum Team. According to Scrum Guide, discussions on scrum.org and Ken Schwaber, The Team means everyone except PO and SM while The Scrum Team consists of these three roles together.
The link http://wiki.scrums.org/index.cgi?ScrumScoreboard is still not working. Is there any information about the scoreboard?
Cihangir Deniz zdemir said on 29 Dec 10 03:39:
Why the Product Owner should not attend the Sprint Retrospective? Greez
Mike Cohn said on 22 Jan 11 11:11:
The statement that the product owner does not attend a sprint retrospective is definitely wrong.
Izikovich Shlomi said on 03 Feb 11 06:50:
The link for "Scrum scoreboard" in the sprint retrospective section isn't working. Can you please update it?
Joshua Chi said on 05 Mar 12 20:52:
In sprint, we don't track how much work has been done. We track how much work left. Also, we change from hour estimation to effort estimation recently. And I found abstract effort estimation is really cool. You don't have to find how many exactly hours you need for a single task. What you want to know is if you can finish it in this sprint or not.
20.
The product owner attends the sprint retrospective (per Schwaber, Sutherland, and Cohn): http://jeffsutherland.com/scrumhandbook.pdf http://www.mountaingoatsoftware.com/scrum/sprint-retrospective http://goo.gl/gr4cy
21.
Hi Victor, I'm not sure where the idea that the Product Owner shouldn't attend the retrospectives came from, but I think it's generally accepted by most SCRUM practitioners to be a good thing for them to do. At my company the PO attends and it's proven to be a good way for the team and the POs to improve the way they work together.
Victor Szalvay currently leads product development for CollabNet's ScrumWorks product suite. In that capacity, he works closely with customers, stakeholders, and the development teams to del... Link
RELATED ARTICLES
by Melanie G. Silver
The Manager's Role in Agile
Quick Links
Frequently Asked Questions Become a Member Code of Ethics Become a Registered Education Provider (REP)
Fine Print
Contact Us Legal Privacy Policy
Stay In Touch
Twitter FacebookFlickr RSSForum
Support