Today's agenda was:
- Definition of done
- Agile Estimating (still continued in the next session)
Definition of Done:
Helps us build the thing right versus the acceptance criteria which helps us build the right thing
There can be various artifacts to call a story or sprint or release done.
For example, we call a story done if unit tests passed or acceptance tests passed.
we can all a sprint done if bugs found during sprint are resolved and release notes are updated.
A release is done when integration tests on deployment build pass and release notes are delivered.
Then we did one more fun exercise to define few artifacts to call various levels done in building a travel web site. For example, travel operators need to follow some govt. compliance so that becomes part of the definition of done.
Agile Estimating:
Different people provide different estimates for the same task. That happens mostly because of different assumptions.
A little effort at understanding requirements and estimating, helps a lot. But a lot of effort would help only a little more.
People are naturally good at comparing things. So there are relative sizing methods. We did an exercise to give some points to various breeds of dogs. Mostly these numbers were from fibonacci sequence. We used smartphone apps for "planning poker" for expressing our estimate of dog point. If there are differences of opinions in estimation, person with far estimate would express why does he think so? And then vote is taken again to reach an agreement eventually.
Estimation is very important topic and is gladly continued.
We are also going to have some guest speakers from industry, so more fun is lined up.
Friday, October 14, 2011
Saturday, October 8, 2011
Third & Fourth session at Agile Management (Scrum Master) course at University of Washington
Oh yes - third & fourth. It was a long Saturday : 9 to 4 :)
Today's session with Stein Dolan, was mostly oriented toward Product Owner (PO)'s role in Scrum, user stories development in large part.
Traditional models like waterfall define what, to reach "low" unknowns' level. At the end, they start implementation part - "How".
Agile models like Scrum define "what" and "how" pretty much together to achieve a decreasing curve, due to simultaneous reactions.
User Stories: are requirement / deliverable for a sprint (or initially production backlog).
Card - Token representing requirement that reflects priority & cost (effort estimate)
Conversation - mostly verbal but possible supplemental documentation can be presented
Confirmation - Acceptance of what needs to be done and called be done.
Card:
As a << user >>
I want to << goal >>
so that << value >>
Where, user - end user of the product
goal - feature
value - why feature is important or gives
For example, As a user I would like my search results to be paginated so that I do not have to scroll through a long list of items
A nice question came up with this: How 500 user stories are better than 500 pages of documentation?
My take is that user stories are very very short, and provider better management possibilities of prioritization and partial releases.
We went through a series of exercises:
Theme: is a collection of related user stories
Epic is a theme when split into smaller stories
Wow, that was a lot in a day. But, lunch buffet was good at Bombay Grill (Indian Restaurant) in University of Washington Seattle campus.
These are just notes that I am taking on my blog, but I want to revisit major topics as I learn more in ongoing sessions.
Onwards...
Today's session with Stein Dolan, was mostly oriented toward Product Owner (PO)'s role in Scrum, user stories development in large part.
Traditional models like waterfall define what, to reach "low" unknowns' level. At the end, they start implementation part - "How".
Agile models like Scrum define "what" and "how" pretty much together to achieve a decreasing curve, due to simultaneous reactions.
User Stories: are requirement / deliverable for a sprint (or initially production backlog).
Card - Token representing requirement that reflects priority & cost (effort estimate)
Conversation - mostly verbal but possible supplemental documentation can be presented
Confirmation - Acceptance of what needs to be done and called be done.
Card:
As a << user >>
I want to << goal >>
so that << value >>
Where, user - end user of the product
goal - feature
value - why feature is important or gives
For example, As a user I would like my search results to be paginated so that I do not have to scroll through a long list of items
A nice question came up with this: How 500 user stories are better than 500 pages of documentation?
My take is that user stories are very very short, and provider better management possibilities of prioritization and partial releases.
We went through a series of exercises:
- Prepare a vision statement for given project definition
(where we want to build a web site to connect various organizations like soccer teams, PTA, church to build communities) - Prepare list of user roles you can think of
(again following the same above short project definition) - Preapre 3 releases and their features
(on how do you want to execute and release some features on the given project) - Prepare user stories
(Write actual user stories for the features defined so far) - Prepare acceptance criteria for user stories
(Write sort of functional tests to define acceptance requirement for the particular user stories)
Theme: is a collection of related user stories
Epic is a theme when split into smaller stories
Wow, that was a lot in a day. But, lunch buffet was good at Bombay Grill (Indian Restaurant) in University of Washington Seattle campus.
These are just notes that I am taking on my blog, but I want to revisit major topics as I learn more in ongoing sessions.
Onwards...
Thursday, October 6, 2011
Second session at Agile Management (Scrum Master) course at University of Washington
Today's instructor was Stein Dolan, from Microsofot.
We learned that Agile is all about Values & Principles. There are defined tools and processes to implement Agile.
Agile Manifesto
We value -
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Should every sprint duration be equal?
Yes - it helps a lot. We can get better data over time which can help determine team's velocity for a given time duration.
Also, team resource changes also should happen at beginning of new sprints only to assure team and sprint efficiency.
We were asked about our goal to join the class.
I have done scrum in the past. I did that with self-learning to begin with, and I liked the visibility Burn-down charts represented.
Then I worked on a project at Microsoft, where we implemented Scrum with the tool - Tackle. That team was rocking. Team members have already estimated the work item in hours. Every day, team would enter hours they worked on any work item, and if they want to re-estimate. So, at the end of the day, we can easily see if everything is on track. I have seen this work, and so much appreciate the visibility. For me - this kind of visibility is primary reason to do scrum. But, I want to know more details on how to build these processes.
We learned about the roles in the Scrum.
Product Owner (PO) - is the person(s) who is responsible for all inputs(requirements) and outputs(releases).
Scrum Master - is the person who facilitates sprint and stand up meetings. He is supposed to make blocking issues and team collaboration smoother.
Team - is responsible to work estimates and implementation.
Product owner focuses on Vision, Product and Releases.
Team focuses on Day, Sprint and Releases.
We are going to perform some exercise on a given project definition. It will fun.
We learned that Agile is all about Values & Principles. There are defined tools and processes to implement Agile.
Agile Manifesto
We value -
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Should every sprint duration be equal?
Yes - it helps a lot. We can get better data over time which can help determine team's velocity for a given time duration.
Also, team resource changes also should happen at beginning of new sprints only to assure team and sprint efficiency.
We were asked about our goal to join the class.
I have done scrum in the past. I did that with self-learning to begin with, and I liked the visibility Burn-down charts represented.
Then I worked on a project at Microsoft, where we implemented Scrum with the tool - Tackle. That team was rocking. Team members have already estimated the work item in hours. Every day, team would enter hours they worked on any work item, and if they want to re-estimate. So, at the end of the day, we can easily see if everything is on track. I have seen this work, and so much appreciate the visibility. For me - this kind of visibility is primary reason to do scrum. But, I want to know more details on how to build these processes.
We learned about the roles in the Scrum.
Product Owner (PO) - is the person(s) who is responsible for all inputs(requirements) and outputs(releases).
Scrum Master - is the person who facilitates sprint and stand up meetings. He is supposed to make blocking issues and team collaboration smoother.
Team - is responsible to work estimates and implementation.
Product owner focuses on Vision, Product and Releases.
Team focuses on Day, Sprint and Releases.
We are going to perform some exercise on a given project definition. It will fun.
Subscribe to:
Posts (Atom)