The word "Done" should not be used in any context except when one is saying the functionality is ready for live. The other word that should be used is either "finished" or "ready"
Mike Cohn has commented on user stories in a very well structured and coherent fashion in his books. A "ready" user story should the follow several attributes known as INVEST:
- Independent – No dependencies between stories.
- Negotiable – User Story is negotiable between the team and the customer.
- Valuable to the user – The functionality dictated by the user story should have value to end users.
- Estimate-able – The scrum team should be able to estimate the user story story
- Small – User Stories should be completed in a single sprint/iteration
- Testable – Test should cover everything that will allow the features to be "Done". This means that the user story should be able to be completed.
Sunday, October 24, 2010
Friday, September 3, 2010
What is your prefered Sprint duration and why?
I would go with shorter sprints. (I go with 2 weeks). From my experience with shorter iterations there are many advantages. Some of those are:
- there are more opportunities to learn from mistakes in 2 weeks than in longer iteration. Retrospectives for example are more frequent within a span of a project which would lead to improved efficiency in the team. (faster in the long run.)
- The team is more focused on what they are working on ( i.e. because of smaller iteration backlog log list) so there will be an increase in quality;
- Easier for everyone to know and understand what everyone else is doing. Example; its easier to understand and comprehend items to be worked by all members in 2 weeks than 4 weeks.
- People will follow the process better.
- there are more opportunities to learn from mistakes in 2 weeks than in longer iteration. Retrospectives for example are more frequent within a span of a project which would lead to improved efficiency in the team. (faster in the long run.)
- The team is more focused on what they are working on ( i.e. because of smaller iteration backlog log list) so there will be an increase in quality;
- Easier for everyone to know and understand what everyone else is doing. Example; its easier to understand and comprehend items to be worked by all members in 2 weeks than 4 weeks.
- People will follow the process better.
What are some of you approaches to doing a retrospective? Do you have any creative activities that can help the facilitae the team to have a dialogue
At the end of each iteration, all the members would meet in a room. One of the members would stand in front of the white board to drive this meeting. Every iteration it would be someone different from the team ( This to prevent strongly opinionated people from taking over the meeting all the time). The one driving the meeting will draw two columns on the board.
1- What went well in the iteration
2- What didn't go well in the iteration
People would make suggestions/comments and the person driving the meeting will be writing on the wall the suggestions/comments in the appropriate column.
When a comment is made on the "What didn't go well" the discussion regarding "what can we do to avoid what didn't go well" is asked and a discussion goes underway naturally. As a SM the expectation is to log this somewhere and follow through some of the the suggestion from this question. You as a facilitator will need to do that to make sure the team can work as smoothly and efficiently as possible.
The expectation in the meeting is that everyone will need try and bring something to the table. If that's not happening, then as a SM you would ask on those not talking about what they think (show that you care about what they think). Eventually it will be the norm for everyone to contribute.
1- What went well in the iteration
2- What didn't go well in the iteration
People would make suggestions/comments and the person driving the meeting will be writing on the wall the suggestions/comments in the appropriate column.
When a comment is made on the "What didn't go well" the discussion regarding "what can we do to avoid what didn't go well" is asked and a discussion goes underway naturally. As a SM the expectation is to log this somewhere and follow through some of the the suggestion from this question. You as a facilitator will need to do that to make sure the team can work as smoothly and efficiently as possible.
The expectation in the meeting is that everyone will need try and bring something to the table. If that's not happening, then as a SM you would ask on those not talking about what they think (show that you care about what they think). Eventually it will be the norm for everyone to contribute.
Saturday, August 21, 2010
How Scrum handles the case when you have 1 scrum master and 1 product owner and 3 teams working in the same product? each team consists of 6 members.
To Answer this question for simplicity, I will assume that we all know how "scrum" in a single team works, and I will assume we will have two teams of 6 rather than 3 to simplify my explanation. This same approach will apply to any number of teams (Proof by induction Anyone? :) )
* In my opinion, a rule of thumb is to make sure that no scrum team is larger than 6 +/- So If you have multiple teams that can be combined into one team of 6 +/- 1, then I would make it one team. Otherwise I would apply "Scrum of Scrums".
* In "Scrum of Scrums", each scrum team has one representative who is most knowledgeable in what everyone is doing in the scrum team.
* The Product Owner will have to have setup two backlog list for the different scrum teams. ( if not, then go based on Epics/themes)
* Each team will have its own iteration planning with the Product Owner going through the remaining items in the backlog list in priority. (so the meeting times need to be adjusted accordingly).
* After the iteration planning, the representatives will have a secondary iteration planing (much shorter) answering the following:
(1)"what we will be working on",
(2)"Any Issues we foresee in our way", and finally
(3)"How do you foresee that our changes will impact you?".
This way each team will know what the other team is working on.
* Daily, each team will have its own stand up meeting. Usually in a stand-up each individual will state
(1)"what I have worked on",
(2)"what I will be working on",
(3)"Any Issues in my way".
* Daily, after both stand ups for each scrum team, the representatives will have a "Scrum of Scrums" stand up meeting. The value I will focus on in this stand up is the "Impact" of a change. The biggest hurdle you will have in a team working on a single product will be the impact of one team making changes that will affect another. In the "Scrum of Scrums" stand-up, there is a bit of a twist to those three questions and a fourth; and they would be
(1)"what have WE worked on",
(2)"what WE will be working on",
(3)"Any Issues in OUR way", and finally
(4)"How will our changes impact you".
The last question will drive the conversation between the representatives on how the changes will affect each other.
* In my opinion, a rule of thumb is to make sure that no scrum team is larger than 6 +/- So If you have multiple teams that can be combined into one team of 6 +/- 1, then I would make it one team. Otherwise I would apply "Scrum of Scrums".
* In "Scrum of Scrums", each scrum team has one representative who is most knowledgeable in what everyone is doing in the scrum team.
* The Product Owner will have to have setup two backlog list for the different scrum teams. ( if not, then go based on Epics/themes)
* Each team will have its own iteration planning with the Product Owner going through the remaining items in the backlog list in priority. (so the meeting times need to be adjusted accordingly).
* After the iteration planning, the representatives will have a secondary iteration planing (much shorter) answering the following:
(1)"what we will be working on",
(2)"Any Issues we foresee in our way", and finally
(3)"How do you foresee that our changes will impact you?".
This way each team will know what the other team is working on.
* Daily, each team will have its own stand up meeting. Usually in a stand-up each individual will state
(1)"what I have worked on",
(2)"what I will be working on",
(3)"Any Issues in my way".
* Daily, after both stand ups for each scrum team, the representatives will have a "Scrum of Scrums" stand up meeting. The value I will focus on in this stand up is the "Impact" of a change. The biggest hurdle you will have in a team working on a single product will be the impact of one team making changes that will affect another. In the "Scrum of Scrums" stand-up, there is a bit of a twist to those three questions and a fourth; and they would be
(1)"what have WE worked on",
(2)"what WE will be working on",
(3)"Any Issues in OUR way", and finally
(4)"How will our changes impact you".
The last question will drive the conversation between the representatives on how the changes will affect each other.
Has anyone used Agile for ERP type projects or with large projects? Any suggestion or inputs are welcome
Yes it can be done. Some pointers (there can be much more)
* You are bound by requirements, audit policies, company policies info, ... etc. so each iteration will need to accommodate for such information. so your estimates need to account for all that are to be done.
* communications. not to enforce it, but rather to facilitate it. If you need to move people to improve this, then do so. if you want a collaboration tool, then get it ( you can use something like SharePoint or Microsoft Access ... etc) . I have dedicated the stand up room to be a place where people will go and talk out solutions to problems.
* stand up, and story board. I cannot stress how valuable these were. anyone lost is back on track just by being in a stand up facing a story board.
* If you have a large team, then apply the "scrum of scrums" concept. keep each scrum team no more than 5 or 6 members. The more people you have, the less communication.
* teach members about scrum.
* keep iterations short. and make it a policy to be ready for live at the end of it.
* focus on quality. this means include unit testing, automated testing, test scripts, manual testing, code review, test script review... etc.
* Last but not least; have a retrospective meeting at the end of each iteration; this will allow the team to reflect back on the it.
* You are bound by requirements, audit policies, company policies info, ... etc. so each iteration will need to accommodate for such information. so your estimates need to account for all that are to be done.
* communications. not to enforce it, but rather to facilitate it. If you need to move people to improve this, then do so. if you want a collaboration tool, then get it ( you can use something like SharePoint or Microsoft Access ... etc) . I have dedicated the stand up room to be a place where people will go and talk out solutions to problems.
* stand up, and story board. I cannot stress how valuable these were. anyone lost is back on track just by being in a stand up facing a story board.
* If you have a large team, then apply the "scrum of scrums" concept. keep each scrum team no more than 5 or 6 members. The more people you have, the less communication.
* teach members about scrum.
* keep iterations short. and make it a policy to be ready for live at the end of it.
* focus on quality. this means include unit testing, automated testing, test scripts, manual testing, code review, test script review... etc.
* Last but not least; have a retrospective meeting at the end of each iteration; this will allow the team to reflect back on the it.
Subscribe to:
Posts (Atom)