Friday, January 28, 2011
Wednesday, January 19, 2011
Plan for the future with Arthur Shelley
When you get back to the office those list of great ideas from the conference has now evaporated. Always remember to record lessons learned and things you want to bring to your business.” – Arthur Shelley
“What will you do when get back to the office? If you don’t do anything you’re losing actionable knowledge.” – Arthur Shelley
“Turn potential into value.” – Arthur Shelley
These are a few of the key take a ways Arthur talked about in his presentation at PWWCBA 2010
Amanda Powers (producer) started the conference off.
Here was the schedule!
Originally posted at agilescout.com
Friday, January 7, 2011
Mary Gorman Says Agile Requirements Not an Oxymoron
Mary Gorman speaking on Agile Requirements: Not an Oxymoron
Requirements are the basis for product development.
So why is Agile requirements not an oxymoron?
Mary had us do an exercise that helped elicit from the group a current state of how people feel about requirements practices for traditional and Agile.
Software development has a lot of interdependencies and complexities.
“Agile requirements planning – We need to look at value first and continually prioritize.”
Agile analysis roadmap:
◦Product – Big-view (Product roadmap – Shaped by the vision, value, goals, and objectives)
◦Release – Pre-view (Product Backlog and Release Plan)
◦Iteration/WIP – Now-view (Iteration Backlog)
Agile development effort:
◦Requirements need to be just enough to begin
◦Requirements need to be testable with user acceptance criteria
◦Requirements have to have a definition of “done”
Ways to visualize work:
◦Data
◦States
◦Rules
◦Interfaces
◦User acceptance tests
Agile requirements and delivering:
Think of sashimi when delivering – Small clean units, bite sized requirements that are as fresh as possible. Delivered immediately and consumed. – Really like this analogy!
Inspect and adapt:
◦The goal is to learn what went well but also adapt and improve as we go forward.
Requirements development & management:
◦Elicit
◦Analyze
◦Specify
◦Validate
In summary, we need smart documentation. Doing smaller chunks of work and working closely with the Product Owner and being ok with incompleteness in total requirements. During the release the requirements are done in full.
So, do we have an oxymoron when it comes to Agile requirements? No way!
Originally posted by www.agilescout.com
Requirements are the basis for product development.
So why is Agile requirements not an oxymoron?
Mary had us do an exercise that helped elicit from the group a current state of how people feel about requirements practices for traditional and Agile.
Software development has a lot of interdependencies and complexities.
“Agile requirements planning – We need to look at value first and continually prioritize.”
Agile analysis roadmap:
◦Product – Big-view (Product roadmap – Shaped by the vision, value, goals, and objectives)
◦Release – Pre-view (Product Backlog and Release Plan)
◦Iteration/WIP – Now-view (Iteration Backlog)
Agile development effort:
◦Requirements need to be just enough to begin
◦Requirements need to be testable with user acceptance criteria
◦Requirements have to have a definition of “done”
Ways to visualize work:
◦Data
◦States
◦Rules
◦Interfaces
◦User acceptance tests
Agile requirements and delivering:
Think of sashimi when delivering – Small clean units, bite sized requirements that are as fresh as possible. Delivered immediately and consumed. – Really like this analogy!
Inspect and adapt:
◦The goal is to learn what went well but also adapt and improve as we go forward.
Requirements development & management:
◦Elicit
◦Analyze
◦Specify
◦Validate
In summary, we need smart documentation. Doing smaller chunks of work and working closely with the Product Owner and being ok with incompleteness in total requirements. During the release the requirements are done in full.
So, do we have an oxymoron when it comes to Agile requirements? No way!
Originally posted by www.agilescout.com