Scrum: Technical Debt and Tetris?

An interesting analogy that involves... TETRIS!!!
The simple idea is that lines with holes in Tetris (that will not disappear) might eventually pile up until you're... dead!
Game over.
Just like technical debt in "scrappy" Scrum:

Technical Debt is like Tetris – Eric Higgins – Medium

BOOK: Agile Software Development with Scrum (Series in Agile Software Development): Ken Schwaber, Mike Beedle: 9780130676344: Amazon.com: Books

The book that started it all, by Schwaber and Beedle (recently disappeared):

Agile Software Development with Scrum (Series in Agile Software Development): Ken Schwaber, Mike Beedle: 9780130676344: Amazon.com: Books

BOOK: Enterprise Scrum (Mike Beedle)

Quoting:
"The focus of Enterprise Scrum is on reinventing the company itself, or any part of it, with all of its business units, customer segments, business models, processes, products, and services.

Enterprise Scrum means Scrum applied to the Enterprise as a whole, so it means continuously reinventing, improving and adapting the company and everything it does.

In 2016, the book Enterprise Scrum: An Adaptive Method for Project Success was published."
Co-Author of Agile Manifesto and Creator of Enterprise Scrum Mike Beedle Passed Away

The blog:
http://www.enterprisescrum.com/

The BOOK: Enterprise Scrum: Agile Management for the 21st Century

https://www.amazon.com/exec/obidos/ASIN/0321807847/

Quoting:
"This is today's definitive guide to making Scrum work at all levels of the enterprise, both in software development and in any other knowledge-intensive business process. Legendary agile pioneer Mike Beedle draws on his experience helping thousands of teams and individuals succeed with Scrum in projects of all types, from single-team assignments to those cutting across complex processes or the entire organization.

Beedle begins with a uniquely clear and practical explanation of Scrum: its roles, benefits, interactions, and how it reflects modern insights into complexity science. You'll master these crucial essentials with the help of clear organizational and process diagrams, as well as exceptionally relevant case studies in software development and beyond.

Building on this understanding, Beedle introduces proven enterprise-level Scrum processes for introducing, growing, and managing operations -- including Scrum's role in the Project Management Office (PMO) and in support of executive activities. He concludes with detailed case studies from multiple domains where Enterprise Scrum has delivered superior results.

Throughout, Beedle helps you understand the paradigm shift required to succeed with Scrum in any knowledge-intensive business process -- and how to gain Scrum's proven benefits of productivity, transparency, and performance."

TOOL: PlanITpoker - Online Scrum planning poker for Agile project teams

An alternative to the use of "planning poker card decks" (or installing some kind of mobile app for that purpose, on every development team member mobile phone - not everyone may have a smartphone handy for planning) a web tool could be used for estimation:

• PlanITpoker: Online Scrum planning poker for Agile project teams

Quoting:
"Pure & Simple Planning
Make Estimating Agile Projects Accurate & Fun
Estimate Like An Expert
Sprint Plan Effortlessly
Play Online Anywhere"

What is Scrumban?

Agile Alliance tells us (in a short article):
What is Scrumban? | Agile Alliance

DIGEST: And the fresh LAST links are...

And the last fresh links are indeed these ones:

The productivity Dept. (send me your suggestions, please): 

• http://silvaonsoftware.blogspot.pt/2016/11/tools-newfilego-productivity-tools-file.html
• Search for TOOLS, Productivity here around. And remember to send me info on your suggestions. 

Additional info on SW Requirements / Requirements Analysis:

1. http://silvaonsoftware.blogspot.pt/2016/05/process-software-requirements-team.html
2. See your QMS "requirements standard" (INTERNAL; includes best practices and conventions). 
3. Read books on the subject and related subjects: Requirements analysis, requirements engineering, business process analysis (a broader topic), writing god requirements. "Google" and/or "Amazon" them.
4. Writing good requirements paper here (PDF)
5. Requirement types: http://silvaonsoftware.blogspot.pt/2016/11/requirements-requirements-types.html

About SW Design / Architecture (and security as well as performance, quality attributes of architectures):

• The VAP info can be found online here (PDF). 

Security topic and the embedded link to the Check List repository:

1. http://silvaonsoftware.blogspot.pt/2016/05/sw-design-security-as-design-quality.html
2. http://silvaonsoftware.blogspot.pt/2016/07/resource-security-is-process.html
3. http://silvaonsoftware.blogspot.pt/2016/08/security-magic-quadrants-for-mss-remote.html
4. Slightly off-topic but equally interesting: http://silvaonsoftware.blogspot.pt/2016/11/security-industrial-control-systems.html

Additional info on Design Patterns, Code Smells, Refactoring (already shown but repeated here for reinforcement or whatever you would like me to call it): 

1. Design patterns: "The index" in Wikipedia is here. 
2. Several books, also called "bibles": The GOF book as well as Code Complete 2. 
3. Another interesting resource is sourcemaking.com (Design Patterns, Anti-Patterns and Refactoring / Code Smells).

Performance (but not only) topic:  

• Performance (and architecture that drives/enables this performance): http://www.javaperformancetuning.com/

Additional resources for SW construction:

1. Static Analysis: 
2. http://silvaonsoftware.blogspot.pt/2016/05/tools-source-monitor-static-analysis.html
3. http://silvaonsoftware.blogspot.pt/2016/05/tools-static-analysis-tools-listing.html
4. http://silvaonsoftware.blogspot.pt/2016/10/sw-construction-static-analysis-tools.html

Additional resources for SW Testing:

• http://silvaonsoftware.blogspot.pt/2016/11/sw-testing-list-of-105-software-testing.html

The Agile Dept.: 
Agile additional info including the Agile state of scrum report, info on Product vision statements rationale and examples, and additional tools as well as books. You will not die without a pile of stuff to read if you follow these final links:

1. Digest 1: http://silvaonsoftware.blogspot.pt/2016/09/starting-learning-agile.html
2. Digest 2: http://silvaonsoftware.blogspot.pt/2016/07/index-agilescrum-index-of-useful-links.html
3. Digest 3 (ufff): http://silvaonsoftware.blogspot.pt/2016/10/digest-agilescrum-links.html
4. BOOK http://silvaonsoftware.blogspot.pt/2016/08/mr-scrum-wrote-yet-another-book-scrum.html
5. The Product Vision "art": http://silvaonsoftware.blogspot.pt/2016/06/about-product-vision.html

And so on. So they say. Happy reading!

(@2017-06-06: fixed req.std.url)

DIGEST: Agile/Scrum links

Agile / Scrum recent relevant links include:

• The Scrum Official Guide we've been browsing (still the July 2013 version): http://silvaonsoftware.blogspot.pt/2016/06/scrum-definitive-guide-scrumorg-agile.html 
• ...and the same Scrum Official Guide in PT-BR:  http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf, 
• ... as well as the summary.
• The INVEST Model that each US shall respect: http://silvaonsoftware.blogspot.pt/2016/04/quality-attributes-invest-on-proper.html
• "Moaning" about the Product Vision: http://silvaonsoftware.blogspot.pt/2016/06/about-product-vision.html

Additional resources related to Agile / Scrum:

• BOOK - The "new" book by Mr. Scrum: http://silvaonsoftware.blogspot.pt/2016/08/mr-scrum-wrote-yet-another-book-scrum.html
• BOOK - Actionable Agile Tools - Jeff Campbell: http://silvaonsoftware.blogspot.pt/2016/06/book-actionable-agile-tools-jeff.html
• (Tip: For additional books filter by the tag BOOK here around).

The Tools Dept.: 

• A task board online tool named Trello (and links to some more used in the context of Scrum like Sococo): http://silvaonsoftware.blogspot.pt/2016/10/tool-online-task-boards-trello-tour.html

(Updated: 2016-10-20, PT BR link; minor rephrases; 2016-11-24: link to summary and minor rephrases; 2017-06-06: actionable book)

Starting Learning Agile...

Some thoughts on starting learning Agile/Scrum (i.e. introductory readings):

If you like the online tutorials format:
http://www.tutorialspoint.com/agile/

If you like "the source" read the full "Scrum Official Guide" by the authors. It is the original (<20 p.) doc, and it is free:
http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf (2013 version)

If you like a summary, use the for dummies series, or the special IBM series, which you can get by registering to IBM (<80 p.). Google says:
http://www.cise.ufl.edu/~manuel/Agile-for-Dummies
https://cs.anu.edu.au/courses/comp3120/public_docs/AgileForDummies.pdf

If you like the handbook format (<40 p.):
http://agilehandbook.com/agile-handbook.pdf

If you like the cheat sheet format, the "for dummies" series typically have them published online:
http://www.dummies.com/careers/project-management/agile-project-management-for-dummies-cheat-sheet/

Mr. Scrum wrote yet another book: "Scrum: The Art of Doing Twice the Work in Half the Time"

Jeff Sutherland (one of the inventors of Scrum) wrote one more book that looks interesting:

• Scrum: The Art of Doing Twice the Work in Half the Time (Barnes and Noble link)
• https://www.amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X/ref=sr_1_1?ie=UTF8&qid=1518784352&sr=8-1&keywords=jeff+sutherland (Amazon link)

Quoting:
"We live in a world that is broken. For those who believe that there must be a more agile and efficient way for people to get things done, here from Scrum pioneer Jeff Sutherland is a brilliantly discursive, thought-provoking book about the leadership and management process that is changing the way we live.

In the future, historians may look back on human progress and draw a sharp line designating “before Scrum” and “after Scrum.” Scrum is that ground-breaking.  It already drives most of the world’s top technology companies. And now it’s starting to spread to every domain where leaders wrestle with complex projects.

If you’ve ever been startled by how fast the world is changing, Scrum is one of the reasons why. Productivity gains of as much as 1200% have been recorded, and there’s no more lucid – or compelling – explainer of Scrum and its bright promise than Jeff Sutherland, the man who put together the first Scrum team more than twenty years ago.

The thorny problem Jeff began tackling back then boils down to this: people are spectacularly bad at doing things with agility and efficiency. Best laid plans go up in smoke. Teams often work at cross purposes to each other. And when the pressure rises, unhappiness soars. Drawing on his experience as a West Point-educated fighter pilot, biometrics expert, early innovator of ATM technology, and V.P. of engineering or CTO at eleven different technology companies, Jeff began challenging those dysfunctional realities, looking  for solutions that would have global impact.

In this book you’ll journey to Scrum’s front lines where Jeff’s system of deep accountability, team interaction, and constant iterative improvement is, among other feats, bringing the FBI into the 21st century, perfecting the design of an affordable 140 mile per hour/100 mile per gallon car, helping NPR report fast-moving action in the Middle East, changing the way pharmacists interact with patients, reducing poverty in the Third World, and even helping people plan their weddings and accomplish weekend chores.

Woven with insights from martial arts, judicial decision making, advanced aerial combat, robotics, and many other disciplines, Scrum is consistently riveting. But the most important reason to read this book is that it may just help you achieve what others consider unachievable – whether it be inventing a trailblazing technology, devising a new system of education, pioneering a way to feed the hungry, or, closer to home, a building a foundation for your family to thrive and prosper."

http://www.barnesandnoble.com/w/scrum-jeff-sutherland/1117655162

Updated - 2018-02-16, Amazon link;

INDEX: The Agile/Scrum index of useful links

To gather some resources and information presented on this site (and mostly available in the internet) here it goes, the Agile/Scrum index of useful links (not exhaustive):

1. http://silvaonsoftware.blogspot.pt/2016/05/scrum-agile-main-documents-and-5-line.html (Resumo do SCRUM Official Guide: 16p. em 5 linhas ;)
2. http://silvaonsoftware.blogspot.pt/2016/07/book-sbok-guide-guide-to-scrum-body (Scrum Body of Knowledge)
3. http://silvaonsoftware.blogspot.pt/2016/04/resource-agile-videos.html (learning through videos)
4. http://silvaonsoftware.blogspot.pt/2016/06/book-actionable-agile-tools-jeff.html (BOOK with additional tools to use with Scrum, e.g. during some Scrum events)
5. http://silvaonsoftware.blogspot.pt/2016/04/quality-attributes-invest-on-proper.html (about the INVEST Model that each US shall respect)
6. http://silvaonsoftware.blogspot.com/2016/06/the-state-of-scrum-2015-report.html (The State of Scrum Report)

BOOK: SBOK Guide - A Guide to the SCRUM BODY OF KNOWLEDGE

One interesting thorough book on Scrum, talking of Scrum of Scrums and many other interesting topics is the SBOK™ Guide (A Guide to the SCRUM BODY OF KNOWLEDGE).
The PDF links are:

• www.scrumstudy.com/download-free-SBOK.asp (English version)
• www.scrumstudy.com/download-free-SBOK.asp?lan=pt ("Portuguese" version)

BOOK: Actionable Agile Tools - Jeff Campbell

The book Actionable Agile Tools - Practical tips and tools from ten years of Agile
(by Jeff Campbell) presents some ideas / tools for better Agile/Scrum.

Some ideas / tools in the book are summarized below (this is the 5-line summary with more or less 5 lines). The book is free to read online, so if this summary it "too summarized", try to read the book.
Remember, as the author recommends, if it works ok. If not, try anything else (move to the next tool and/or idea).

Better sprint retrospectives

SR is also sometimes called "coffee room whining ceremony"

• Talk about everything
• It's someone's else fault
• Nothing changes

Retrospective:

• Talk about one thing
• What can we do?
• Experiments

Retrospective vs project post-mortem = bad term

• symptom
• root causes
• experiment: Start... ; start...
• success criteria: At least 2 bugs prioritized at each sprint (for example)
• follow up: In 4 weeks; actionable person (that can delegate to others)

Post-its with names and flowers

Showing recognition (in front of the team) increases team spirit.

Tools for iterations

Who knows what "sprint 15" is or means (a few months after it was done)?
Solution: choose a tasty theme; name sprints alphabetically: apple pie, blueberry pie, chocolate cake, etc.
Eat the thing (really)
Enjoy.

Tool: Bugs for breakfast

A tool for quality: legacy products in bad shape?
Have a ceremony once per week (approx.)
Focus on quality-related things.
Examples:

• unnapropriated tool in area X
• few tests
• fix issues
• create test

List anything that contributes to increased quality. And manage actions derived from the meeting.

Tool for data based decisions

Scrum. Board

Ticket for:
planned, critical, support, meetings, admin

Make ticks in the wall per hour spent or per type of activity performed (to count ticks in the end).

Tool for retrospectives: Event log

Board with dates and what happened (for remembering those events easily later on)

Tool: Door calendar

Useful for production releases.

Move post its (as production releases dates change, if they change).
That way everyone sees it (if it is in the door).

Tool: Resilience map

Tool for cross functionality.
SPOF: To be avoided (at all costs)
Build a matrix of skills vs team member name, basic, med., high
That way it is easy to spot the gaps (where is the issue, if smth goes wrong with that system/skill we are blocked)
Show it to managers (the gaps become more evident and the team might be reinforced, or having more training as a result)

Tool: in-line definition of done

A tool for quality (so that no-one forgets checking everything before marking things as done).
US cards can have the checklist printed next to the / in the US card.

story name / DoD (check list, answer could be N/A for this US)
task name / DoD (could be different than the one for US)

Morning meeting protocol 

A tool for meeting efficiency.

Boring daily meetings?
Morning meetings should be energizing:
anything to share?
anything today?
does anyone needs our help?
any unplanned tasks?
is JIRA up to date?
is the build up to date? Jenkins?
etc,

WIP tool

A tool for kanban:

who ignores the WIP?
3 rules broken frequently

When blocked what should we do?
Wait? Or start new task?
What to do? Work in this order:

• cofee
• try to unblock blocked items
• see I somone can finish off halted olwork off the mob
• use the tech swimlane (technical debt)
• have a retro on blocked items (if they are so many and being consistently a problem)

Tool: Not now backlog

A tool for dealing with "junk" (old epics and user stories that are in the PBL for ages).

1st: Convince to throw the huge backlog away

If not successful use this tool:

• decide what now means: Q1,1,month
• create a "deep backlog"
• move all the crap you never going to do and...
• forget about it

Tool: Visualized flow - a tool for refinement

The team "commits" to the sprint just to leave the room: Estimate and leave the room (while sometimes asking questions about the US in the process). If so use this tool:

First:
Several lanes: Customer | Team | Bugs | Marketing | Backlog
Move to the last lane IN ORDER
(top items have higher priorities)


Second:
backlog. PO refinement. Team refinement. Ready: Move items to the last lane as they are really ready (in order?)


Third:
Only choose ready items that are ready that fit the sprint

Fourth
Sprint = Todo... Deployed | Closed

Fifth

Show progress in another task board, so that other stakeholders understand and see the progress.
The task board shows the sprint contents in different lanes (so that they know that that MKT feature is being done)

These tools help to Facilitate communication (to other departments in the company)

The bottom line

Don't try to make teams make something that they don't want to do.
Try the approach (to pass the initial resistance): Let's have it a try for 3 weeks and then analyze results. Again, if it works ok. If not try anything else (move to the next tool and/or idea).

Further info at: https://leanpub.com/actionableagiletools

(2016-06-09: typos - kudos R. Azevedo)

Scrum Definitive Guide | Scrum.org (Agile)

This is the link to "The Definitive Guide to Scrum" (developed and sustained by Ken Schwaber and Jeff Sutherland, scrum.org, and also known as Scrum Official Guide or SOG), 16 pages that changed the way we produce (some) software:

• http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf: July 2013 version; older versions include May 2009 and October 2011. PS. In 2016 a new version of the guide was provided by the authors.
• The 2017 version is here: http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf#zoom=100 and can be browsed online here: http://www.scrumguides.org/index.html
• In PT BR: http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf

(@2016-06-08: Added aka; 2016-10-17: added PS; 2018-02-21: rephrased, added link to V2017; added link to PT BR version)

The State of Scrum 2015 Report - Scrumalliance.org (PDF)

Interesting PDF report from the organization that manages the framework:

https://www.scrumalliance.org/scrum/media/scrumalliancemedia/files%20and%20pdfs/state%20of%20scrum/scrum-alliance-state-of-scrum-2015.pdf

Quoting:
"The State of Scrum reports offer comprehensive coverage of global usage of Scrum -- who is using Scrum, where, how, and why. The report also looks at how and where Scrum is best adopted and is growing. "

PS. Heard of it from the "Fluffy Side of Scrum" book authors @ Agile Portugal 2015 (2016-06-05).
(@2016-10-13: Added quote)

About the Product Vision

A vision and a Product Backlog: What is needed to start Scrum (according to one of the maintainers of the Scrum Official Guide).

About the Product Vision including some PV samples:

• https://www.quora.com/What-are-some-good-examples-of-a-product-vision
• https://www.prodpad.com/2015/03/think-big-the-product-vision-exercise-for-product-managers/

Product Vision Template:

Work through the PV template together with the key stakeholders in the same room:

"For <target customer>

Who needs <statement of the need or of the opportunity>

The <product name> is a <product category>

That <key benefit and/or reason to buy>

Unlike <primary competitive alternative>

Our product <statement of primary differentiation>"

Test the product vision statement with the elevator pitch (If you can’t pitch what you have in 30 seconds, your product vision isn’t still finished - rework it).

• Source: https://www.prodpad.com/2015/03/think-big-the-product-vision-exercise-for-product-managers/ and adapted from the book https://en.wikipedia.org/wiki/Crossing_the_Chasm (Geoffrey A. Moore).

(@2017-05-29: Added PV template link/info)

Scrum (Agile) main documents and the 5 line summary (or not)

Scrum main documents include:
- The Agile Manifesto: the rationale behind scrum agile methodology.
- The Scrum Official Guide: maintained by the 2 framework authors up until... today (July 2013 version here).

The guide describes in merely 16 pages (!) a "new" ground-breaking framework for [software] product development. I give you the "5 lines" summary (as if it was needed):

• Pillars:
• Transparency (progress towards the Sprint Goal; definition of Ready is a transparency measure also)
• Inspection: several opportunities for inspection (events, etc), but not so many that gets in the way (of reaching the sprint goal)
• Adaption: if something is found it shall be fixed (or annotated as technical debt) 
• Roles:
• PO (the owner of the product backlog; one person not a committee); can delegate but is still owner, 
• SM (the facilitator; ensures scrum is understood; services to the PO, to the Dev. Team and to the Organization), 
• Development Team (cross-functional, please; self-organizing - SM does not need to tell what's next): 3 to 9.
• Events: All time-boxed (fixed max. duration)
• The Sprint; fixed duration (fixed team); could be cancelled (if the sprint goal does not make sense anymore); max. 4 weeks.; if cancelled, Done items shall be reviewed all the same (by the PO)
• [Sprint] Planning: all team; choose "Ready" items from the PBL to the Sprint BL (after defining and having the Sprint Goal defined; do not choose non-ready items. Leave unplanned buffer (%); use sprint velocity from previous sprints (team DOES not change and is allocated 100%; what to do next sprint and part 2: how to do (technical aspects included); time-boxed to 8h (1 mth sprint), proportionally smaller for smaller sprints.
• Daily Meeting: 15 mins, SM and Dev. Team; if SM is not present shall delegate; optional: SM presents team progress (burndown chart) at start; each developer: what I've done, what I'll do today; what is blocking me (to be solved in 1-2 mins or at a tech meeting with relevant stakeholders afterwards); stand-up meeting. 
• [Sprint] Review: all team; review US definition (including Acc. Criteria) and demonstrate that it is Done. present all "Done" US to the PO. Answer questions, interact with the software, inspect results, answer to questions. Rework could be raised - as new US (even if the story is Accepted - changed to the Closed status by the PO ideally); time-boxed to 4h (1 mth sprint). 
• Retrospective: All team (w/o PO); think of lessons learned; what to start doing, stop doing (think on  people, relationships, process, and tools); raise actions to fix (or study the); provide status of previous actions until closure; remember to plan for those actions to be closed also in Sprint Planning; time-boxed to 3h (1 mth sprint).
• NOT AN EVENT: Refinement, Backlog Grooming, Pre-planning meetings: Prepare US to be "Ready" (PO, SM & parts of Team); convert Epics (Themes, high level features) to "Ready" US; use planning poker estimation technique; each and every US shall respect the INVEST model. 
• Planning poker estimation technique: estimate story points - cards deck or mobile app
• Definition of "Done": Transparency; informal: Definition of "Ready". All tasks that should be completed before some US can be stated at that status.
• Events sequence for 2 wk sprint: Planning, Daily(ies), Pre-Planning (several meetings, second week), Review (Demo, last 1-2 days); Retro: after Review (friday).

• 2 Artifacts: 
• PBL: Contains PBI: Epics / Themes, User Stories (Drafts, Ready), other tasks (setup, documentation, ...): owned by the PO (which can delegate); is an ordered list (by priorities, at least for the items for next sprints)
• Sprint BL: Contains Ready US chosen from the PBL to fulfill the Sprint Goal + other tasks (unplanned, research spikes, technical debt, other tasks such as technical documentation tasks - not to be delivered in the increment - , etc.); the potentially shippable product increment contains the "Done" US (only those approved by PO)

• AOB: 
• Research spike; technical debt; pigs and chicken, potentially shippable product increment = increment = something that can be incorporated in the shipped product. 
• Burndown chart (personal and for the team): Ideal curve; Are we late? How many (hours, US) do we need to do to converge to ideal curve; estimation accuracy; important for self-control. Important to report effort daily.
• Taskboard: Ready - In Progress - Done - Closed / Reviewed (use post its on the wall if no IS is available)
• Tools to support: dash boards for auto-control; task board; storage for US; issue tracker (for other tasks/actions). 

More interesting resources include:
- Scrum Glossary: https://www.scrum.org/Resources/Scrum-Glossary
- Resources: https://www.scrum.org/Resources

(2016-06-06: add. links at end)

RESOURCE: Agile/Scrum Videos

Here's an interesting resource on Agile/Scrum:

• http://scrumtrainingseries.com/

Quoting:
"Free Online Scrum Master Training: The fun way to learn about Agile/Scrum, prepare for Scrum Master certification / Agile certification (CSM, CSPO, etc.), and debunk popular misconceptions."

PS. Kudos to Cátia M for sharing this with the rest of us.

Quality Attributes: INVEST on Proper User Stories

User Stories (US) are important Product Backlog Items (PBI) on Scrum.

When they are deemed "Ready" this means that they are ready to be inserted in the scope of a Sprint. When they are not ready, this means that the appropriate level of detail (and peer review) was not yet achieved. They were not yet subject to "refinement" (previous terminology included the term "Product Backlog Grooming"). As a developer don't touch them.

When they are "Done" this means they are ready for the PO approval.
The definition of "Done" is an important part of Scrum (relates to transparency) and deserves a full section on the Scrum Official Guide. There could also be a Definition of Ready (but this is optional).

The INVEST model

Each and every user story shall possess the INVEST quality attributes. Refine an Epic into User Stories and before considering them "Ready" make sure that the INVEST model is applicable to each one of the user stories you are working on:

• The INVEST acronym (for Scrum US): https://en.wikipedia.org/wiki/INVEST_(mnemonic)
• The original article from Bill Wake (author of the "Exploring Extreme Programming" XP123 blog) can be found here: http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

PS. The latter link has a variant definition for the SMART Acronym for requirements: SMART tasks.

Agile/Scrum software development

Agile / Scrum is being more and more widely used as a methodology for developing software.
There are lots of resources on agile/scrum. I will simply list some of the main resources for future reference:

• The agile manifesto: http://agilemanifesto.org/
• The main principles: http://agilemanifesto.org/principles.html
• Some "history" can be found here: https://en.wikipedia.org/wiki/Agile_software_development
• The scrum guide (official) can be found here: http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf

Personally, I like the simplicity of the thing (but please bear in mind that agile is not suitable for all development - more on that at the end of this topic). Sometimes the world is changed by people "thinking out of the box". These people (listed here) started in the nineties thinking on alternatives to Waterfall methodologies. Waterfall and other more classic methodologies fit well into mature markets (aerospace, railway and transportation, amongst other), but are not so suited for low level maturity clients, customers that don't know very well what they want (but do not mind paying for the changes they request), product development, research and development as well as other "fast changing" projects.

And as we know that "change is part of life", why not having a way of dealing with it elegantly, or at least with a little "less drama" (scope negotiations, contract negotiations that may do more harm than good to your relationship with the customer)?