StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>In a Scrum project, anything that needs to be done should be entered as a task.</p> <p>One of the key points of Scrum is being able to accurately predict what a team can get done in a sprint. In order to do this, you must account for everything that is going to consume a developer's time.</p> <p>This means that things like documentation, testing, and peer reviews must all be taken into account as tasks.</p> <p><strong>Edit:</strong> Based on Mendelt's post, I'm going to clarify things a bit.</p> <p>From <a href="http://en.wikipedia.org/wiki/Scrum_(development)#Product_backlog" rel="noreferrer">Wikipedia</a> :</p> <blockquote> <p><strong>Product Backlog:</strong> The product backlog is a high-level document for the entire project. It contains broad descriptions of all required features, wish-list items, etc. It is the "What" that will be built. It is open and editable by anyone. It contains rough estimates, usually in days. This estimate helps the Product Owner to gauge the timeline and, to a limited extent, priority (e.g. if "add spellcheck" feature is estimated at 3 days vs 3 months, that may affect the Product Owner's desire).</p> <p><strong>Sprint Backlog:</strong> The sprint backlog is a greatly detailed document containing information about how the team is going to implement the requirements for the upcoming sprint. Tasks are broken down into hours with no task being more than 16 hours. If a task is greater than 16 hours, it should be broken down further. Tasks on the sprint backlog are never assigned, rather tasks are signed-up for by the team members as they like.</p> </blockquote> <p>Items on the <em>Product Backlog</em> will not show things like documentation or testing, but the tasks on the <em>Sprint Backlog</em> most certainly should.</p> <p>I'll give an example. Say there is a "Feature A" on the Product Backlog, and its estimated time is 1 week. On the Sprint Backlog, that might be broken up into the following tasks:</p> <pre> Initial design document: 4 hours Development of subset 1 of Feature A: 8 hours Peer review of subset 1 of Feature A: 2 hours Testing of subset 1 of Feature A: 6 hours Development of subset 2 of Feature A: 8 hours Peer review of subset 2 of Feature A: 2 hours Testing of subset 2 of Feature A: 6 hours User Documentation for Feature A: 4 hours --------------------------------------------- Total time 40 hours </pre> <p><strong>Edit #2:</strong> The idea behind the Sprint Backlog is to be specific as humanly possible about exactly where you have to spend your time. This is why tasks cannot be more than 16 hours long and it is how you get to a point where you can be very reliable in your schedule predictions.</p> <p>If you follow the Sprint Backlog guidelines religiously and make sure to include <em>everything</em> that you spend development time on then you will be pleasantly surprised at how accurate your scheduling can be after a few sprints of practice.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload