Basics Of Agile

Agile Tenants

We value those on the left MORE then those on the right. 
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Stories

- Customer focused
- Can be explained in 30 seconds or less to someone
- Size enough to fit into one sprint
- Testable 
Base Example:
As a USER, I want to SOMETHING, so I can SOMETHING.

Acceptance Criteria

Each story on the back should have a list of acceptance criteria
Success:
Opening of application successfully pulls twitter feed
Display multiple graphs
Allow graph overlays
Ability to color edit
Failure: 
Display easy to read text data if graph portion fails
Visually appealing error image

Product Backlog

Prioritized list of stories sorted by business values / risk / complexity
Each story is estimated by the team based on complexity 
This provides solid insight into how difficult a task could potentially be resulting in a product with the best business value
This list is then used to create each sprint based on the Product Owners vision

Sprints

The sprint backlog is the level of work teams have agreed to take for their 2 – 4 week sprint
By keeping it in a set time box we begin to derive how much work a group can produce
We also begin to see what kind of noise (or interference) some members of the team face day to day 
This allows for us to see what blocks are occurring and try to find better ways to help us increase our productivity
Each sprint contains a Sprint Backlog that is derived from the product backlog
 - This is the work committed to by the team
 - Stories are broken down into time measurable tasks

Tasks

Once stories are selected into a sprint during sprint planning the team (not the Scrum Master or Product Owner) breakdown the stories into tasks
These are easy to understand pieces that need to be done to complete a story 
 Example: 
Create graphical layout mockup
Code display graphs
These are then estimated by the team based on pure hours
Pure hours are a measure of time for someone to do something with ZERO distraction 
 Example: 
Create graphical layout mockup – 2h 
Code display graphs – 18h

Stand Up

- Typically in front of a planning board we have a daily meeting which is routinely called “Stand Up”. This is a quick 10-15 minute meeting that 

we hold that is primarily for the team (which anyone is welcome to attend as long as they do not disrupt the meeting)

- In this meeting we give a quick red, yellow, green status about what we are working on along with a brief update on what we will be working on for the day
- We can then make note of the individuals having problems and after this meeting work on having separate discussions to address how we can remove these issues
- This meeting allows for everyone to see how everyone is doing, offer help, and bring instant visibility to any issues so that they can be resolved in a timely fashion.

Review/Retrospective

- Once a 2-4 week cycle is completed a review/retrospective is preformed. 
- A review is typically a demonstration of some type showing off the work and progress being made. This meeting can be held in a small group setting or company wide. 
- Lastly we preform a Retrospective. From this we get together as a group and find out what we should keep doing, start doing, and stop doing.
These can then be turned into action items that we can later implement in future sprints to help improve upon performance.

Scrum Team

Product Owner

- Voice of the customer
- Defines the features of the product or desired outcomes of the project
- Chooses release date and content based on business needs
- Ensures profitability (ROI)
- Can change the course of the project at the end of every Sprint
- Accepts or rejects work results
- Prioritizes features/outcomes according to market value
- Communicates status externally
- Can terminate a sprint if something is determined to be drastically more important 

ScrumMaster

- Ensures that the team is fully functional and productive
- Enables close cooperation across all roles and functions
- Removes barriers
- Shields the team from external interferences
- Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint planning
- Facilitates the daily scrums

The Team

- Is cross-functional
- Is right-sized (the ideal size is seven -- plus/minus two -- members) 
- Selects the sprint goal and specifies work results
- Has the right to do everything within the boundaries of the project guidelines to reach the sprint goal
- Organizes itself and its work 
- Demos work results to the product owner and any other interested parties.

Helpful Links

- http://www.scrumalliance.org
- http://en.wikipedia.org/wiki/Scrum_(development)
- http://www.mountaingoatsoftware.com/topics/scrum