Go to the top

New to Agile Scrum

josehassan / Blog / 0 Comments
New to Agile Scrum

title=””England-Scotland-3-2-07-CC-7″ by Unofficial England Rugby’s photos – Flickr. Licensed under CC BY 2.0 via Wikimedia Commons – https://commons.wikimedia.org/wiki/File:England-Scotland-3-2-07-CC-7.jpg#mediaviewer/File:England-Scotland-3-2-07-CC-7.jpg”>”England-Scotland-3-2-07-CC-7}” by Unofficial England Rugby’s photos – Flickr. Licensed under CC BY 2.0 via Wikimedia Commons – https://commons.wikimedia.org/wiki/File:England-Scotland-3-2-07-CC-7.jpg#mediaviewer/File:England-Scotland-3-2-07-CC-7.jpg

An Agile User Story is identified as a “very high-level definition of a requirement, containing just enough information so that the developer can work out” an estimate of the anticipated Tasks needed to develop, test, and release the ultimate business product value for a Stakeholder (a Customer or User) as in a desired Stakeholder’s Feature, defined at a very high-level within the Product Backlog.

‘Themes’, ‘Epics’, ‘Stories’, ‘Features’, and ‘Acceptance Criteria’s are labels associated with items listed in a Product Backlog, preferably in the in the form of an Agile User Story. Listing these items in a Product Backlog, as a User Story, is the responsibility of the Product Owner in collaboration with Stakeholders. The relative size of these listed items; their interrelationships or interdependencies to each other is at first vague, because of the high level definition of an Agile User Story; the relationship of a Theme size User Story to an Epic User Story is relative in scope or size, as is the relation of an Epic User Story to a ‘ Story’, each decomposes into finer Features.

Decomposition of a Theme

Decomposition of each higher level Agile User Story breaks down into Tasks; these Tasks are essential to delivering the Stakeholder‘s ‘wish list’ of Features by the Scrum Team, and the Tasks relative to delivery of the Features are determined during the Session 2 of a Sprint Planning Meeting. The Sprint Planning Meeting consists of two sessions, from which each development Task is associated to a delivery schedule as part of the Sprint plan and is also listed in the Sprint Backlog; once each Task is part of a Sprint, it may be listed on the Scrum Team’s ‘Task Board’; a Task progress is updated daily at the Scrum Teams’ stand-up meeting, the Daily Scrum (15 Minute Time Box), and can be visually tracked by a Scrum Master on an artifact referred to as a ‘Sprint Burndown’ chart, that corresponds to a visual interpretation of progress, hence Velocity.

Breakdown into Tasks

It’s worth noting that the Scrum tools used in Agile to aid in collaboration, such as the Product Backlog, Sprint Backlog, Task Board, Sprint Burndown, and other charts, are referred to as Artifacts.

A Sprint Planning Meeting is ‘Time Boxed’ to 4 hours and is scheduled by the Scrum Master; the Scrum Team starts with examining the Product Backlog, aided by the Product Owner, as in Session 1 of a Sprint Planning Meeting; the Product Owner is there to facilitate the Scrum Team’s understanding of the User Stories required to address Stakeholder needs and anticipate the delivery of these Features in a Sprint.

Themes are Large User Stories that decompose into relatively smaller, Epic User Stories; Epics decompose into smaller User Stories (Stories) during Session 2 of a Sprint Planning Meeting; with or without the presence of the Product Master as an observer; first each User Story is assessed and estimates are made as to the effort or amount of work broken down into associated Tasks. The collection of all the Task estimates, estimated by the Scrum Team, provides a good probability of the total amount of project effort involved in completing an entire Sprint.

(Story Points: Arguably the relative organizational maturity and working experience of the developers on a Scrum Team most influence the value associated with a baseline ‘Story Point’, as used in a ’Story’ to Story’ or even finer ‘Task’ to ‘Task’ comparison. Particularly when used to size the complexity of deliverables, but for the purpose of this article; references will be made to a ‘Widget’ instead.)

A useful technique for estimating the amount of work of each developer Task is the ‘Story Point’, which is based on the ‘Fibonacci Scale’; the ‘Fibonacci Scale’ provides proportionally larger expanses of numbers for comparing ‘Stories’ or ‘Tasks’; this predisposes a Scrum Team to reach consensus on the relative levels of value assigned a deliverable Task. Estimates made by a Scrum Team using the “Story Point” technique, are based on a known relative value of a Task. “Story Point” is not a rigorous technique used to estimate when the work will be completed, consider the organizational maturity and experience of the Scrum Team. “Most teams also estimate how many hours each task will take someone on the team to complete.”, but whether a Task can or should be estimated in Hours, is not a discipline of ‘Story Points’. Using Story points ‘Stories’ or ‘Tasks will fall in to buckets estimated in 1, 2, 4, or 8 widgets; items that fall in between buckets, will fall into the next larger ‘bucket’; even larger Tasks are estimated in widgets and fall into ‘buckets bigger widgets’, such as 2 widgets, 3 widgets, 5 widgets, 10 widgets; estimates in widgets; those Tasks which fall in-between buckets, will always fall into the next higher ‘bucket of widgets’. Exceedingly larger items are similarly estimated in a ‘bucket of largest widgets’, such as 1, 2, 3, or 6 largest widgets, such items are generally ‘Themes’ or ‘Epic’ in proportion, and will need to be broken down substantially before the work is done, and as before those ‘bucket of largest widget’ estimates, which fall between buckets, are entered in the next higher bucket.

With the estimated amount of work in context, the Scrum Team is now ready to plan out several Sprints. Sprints are described as “short duration Milestones” these allow teams to tackle manageable pieces of the project and get the project into a ‘Done’ state. Sprints may be ‘Time Boxed’ to last from 1 week (2-5 days) to 6 weeks (30 days) of work, depending on the Product Release cycles, the shorter the release cycle, the shorter the Sprint.

If you have questions, keep digging, but below are some links I found a helpful start:

Scrum and Agile Glossary at http://www.scrumstudy.com/search.asp

Theme Scoring at http://www.mountaingoatsoftware.com/tools/theme-scoring

SBOK™ Guide http://www.scrumstudy.com/sbok-guide.asp

New to Agile Scrum in Under 10 Minutes – What is Scrum https://www.youtube.com/user/axosoft?v=XU0llRltyFM

Scrum et al presented on Google Tech Talks https://www.youtube.com/watch?v=IyNPeTn8fpo

Free Resources http://www.scrumstudy.com/free-resources.asp

The Scrum Guide by Jeff Sutherland and Ken Scwhaber: http://www.scrumguides.org/download.html

Agile Introductory program www.izenbridge.com/pmi-acp/free-pmi-acp-introduction/[/vc_column_text][/vc_column][/vc_row]

Leave a Comment