I get many questions regrading where to find a good source to learn "Scrum". One of my favourite is
http://www.mountaingoatsoftware.com/topics/scrum
Thursday, November 18, 2010
Wednesday, November 3, 2010
Is the Sprint truly complete if QA still has work to do and how should it be solved using SCRUM?
Consider this as a solution. I will explain the reasoning behind after the solution. I do not know how big the team is, but I am working based on a 3 developers, 2 analysts scenario... the ratio can be changed....
>>Solution:
- Have Analysts. One position that cover both QA and business analysis roles.
- Keep user stories short.
- Release as often as possible to your testing environment. Every day, or every time a testable section is available.
- Consider regression testing every iteration. If automated, consider it more often than once every iteration. If manual, then at least once. (i.e. also consider this in iteration planning/Estimation)
- Extra: Consider unit testing. This will promote the team to focus on quality, rather than functionality.
- Define "done" as ready for live.
>>Reasoning:
Each iteration analysts are working on user stories for future iterations and test scripts for the current iteration. Also have another analysts taking on the role of testing the functional scripts of a user story not worked by him/herself. Once deployed to the testing environment, the analyst will test. The aim here is to avoid lingering untested features and undiscovered bugs from being in the system for too long. By doing the above, you will have the analysts busy with user stories and testing, thus eliminating the worry of people not having work to do.
By having user stories small enough, you will have proper functional testing, and since you are covering for regression testing, you are ensuring all testing from your end. within the iteration, you covered for the unit, functional, and regression testing.
If doing manual regression testing, then analysts, and developer cover the testing using the test scripts to ensure coverage.
Remember that in scrum, you use the "Skill set" and not the "role" or "position" of a person. so "theoretically" you can have developers only who are good at user stories/dev/testing... etc. So when dealing with an issue. think of the team doing something rather than the person with such and such role doing something.
>>Solution:
- Have Analysts. One position that cover both QA and business analysis roles.
- Keep user stories short.
- Release as often as possible to your testing environment. Every day, or every time a testable section is available.
- Consider regression testing every iteration. If automated, consider it more often than once every iteration. If manual, then at least once. (i.e. also consider this in iteration planning/Estimation)
- Extra: Consider unit testing. This will promote the team to focus on quality, rather than functionality.
- Define "done" as ready for live.
>>Reasoning:
Each iteration analysts are working on user stories for future iterations and test scripts for the current iteration. Also have another analysts taking on the role of testing the functional scripts of a user story not worked by him/herself. Once deployed to the testing environment, the analyst will test. The aim here is to avoid lingering untested features and undiscovered bugs from being in the system for too long. By doing the above, you will have the analysts busy with user stories and testing, thus eliminating the worry of people not having work to do.
By having user stories small enough, you will have proper functional testing, and since you are covering for regression testing, you are ensuring all testing from your end. within the iteration, you covered for the unit, functional, and regression testing.
If doing manual regression testing, then analysts, and developer cover the testing using the test scripts to ensure coverage.
Remember that in scrum, you use the "Skill set" and not the "role" or "position" of a person. so "theoretically" you can have developers only who are good at user stories/dev/testing... etc. So when dealing with an issue. think of the team doing something rather than the person with such and such role doing something.
Sunday, October 24, 2010
What could be a list of potential definition of "Done" for user stories?
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.
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.
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.
Tension within the team. Does anyone have any recommendations on how to handle personal tensions within a team?
A ScrumMaster (SM) is a facilitator and an example for a scrum team. Based on this premise, below are some ideas that might help.
1- If people in the group are in disagreement/tension, then let them work it out.
2- If they are not working it out, then create the right environment to work it out. have the stand-up room available for people to talk things through. If they want more privacy, then they close the door and talk it out.
3- If there is still an issue, then be the mediator. The SM's job is to "clear hurdles" for individuals in a scrum team, not just watch them deal with it. To clear this hurdle, you have to act as a mediator. No need to bring a third party unless you as the SM are in tension with others (but as an SM, I would really hope not). In my opinion, the more people you involve in a tense situation, the more complicated it will be and harder to resolve.
4- Be an example to everyone. As painful as it seems, be the most patient person ever when dealing with such a problem.
5- The best way to avoid tension is to anticipate it. And how do you anticipate it? By getting feedback from the team. I am THE BIGGEST FAN of the retrospective meeting. This 45 min every iteration meeting is a key to relief people stresses in future iterations. Less stresses for individuals in a team will make them happier in the team which makes them more patient and thus less tension. Of course, as a SM I would expect you to follow through in making and/or allowing the proper changes based on the retrospective.
6- Smile, and crack a jock every once in a while (even if you are bad at it), people who are more skilled at jokes will get the courage to do so later on.
1, 2, 3 are for specific individuals in disagreement
4, 5, 6, are for the team and future "way" to reduce tension in general
In regards to the original question, to reduce tension in the team as a whole, I would start off with the retrospective. To reduce tension between specific individuals in the team, then I would apply 1, 2, then 3
1- If people in the group are in disagreement/tension, then let them work it out.
2- If they are not working it out, then create the right environment to work it out. have the stand-up room available for people to talk things through. If they want more privacy, then they close the door and talk it out.
3- If there is still an issue, then be the mediator. The SM's job is to "clear hurdles" for individuals in a scrum team, not just watch them deal with it. To clear this hurdle, you have to act as a mediator. No need to bring a third party unless you as the SM are in tension with others (but as an SM, I would really hope not). In my opinion, the more people you involve in a tense situation, the more complicated it will be and harder to resolve.
4- Be an example to everyone. As painful as it seems, be the most patient person ever when dealing with such a problem.
5- The best way to avoid tension is to anticipate it. And how do you anticipate it? By getting feedback from the team. I am THE BIGGEST FAN of the retrospective meeting. This 45 min every iteration meeting is a key to relief people stresses in future iterations. Less stresses for individuals in a team will make them happier in the team which makes them more patient and thus less tension. Of course, as a SM I would expect you to follow through in making and/or allowing the proper changes based on the retrospective.
6- Smile, and crack a jock every once in a while (even if you are bad at it), people who are more skilled at jokes will get the courage to do so later on.
1, 2, 3 are for specific individuals in disagreement
4, 5, 6, are for the team and future "way" to reduce tension in general
In regards to the original question, to reduce tension in the team as a whole, I would start off with the retrospective. To reduce tension between specific individuals in the team, then I would apply 1, 2, then 3
Subscribe to:
Posts (Atom)