- programmable tasks and written in a white board together along with the time estimates for completion. If you have never seen a product backlog, you can check few samples here in QAZone . Sometime real customers are invited to the kickoff meeting as well to review and clarify the product backlog with the agile team.
- The next step in the sprint/iteration planning , in which the team collectively decides the sprint goal and sprint backlog (list of prioritized work to be done for that particular sprint). While the team is collectively creating the sprint backlog, stories need to be broken into either sub-stories or smaller tasks. During this collective team exercise you can really see the differences in project management (at least if you have a more rigid and formal waterfall like type of background), because there is no management authority that assigns tasks to team members. On an agile team all the members jointly associate level of difficulty to specific tasks, they can remove or add additional stories and/or tasks, and tasks are distributed among the team on a per volunteers basis. Unlike a traditional project manager function, the ScrumMaster role in this meeting is to maintain the backlog list in the meeting based on team feedback and consensus, make sure that nobody is volunteering for too many tasks to the point of overload, and facilitate the process of building personal commitment to the team.
- Now that the Sprint planning is ready in the form of sprint backlog –which is dynamic and not set in stone, in fact it is very likely that it will adapt and change based on new stories, new tasks and/or impediments found throughout the iteration– scrum meetings will be set at the same time and in the same place on a daily basis. If you have never attended a scrum meeting, these meetings are very dynamic in nature and fast, never more than 30 minutes, and ideally 10-15 minutes. The objective is to go around so each team member can answer 3 questions: what have I accomplished since the last meeting (developed, tested, written, etc), what will I be working on next, and what are the problems, if any, preventing me from accomplishing my goals. These meetings are very important to make sure that the team moves towards achieving their sprint goal, or adapts/evolves and changes priorities and tasks as needed if new stories, impediments or new scenarios are encountered.
- At the end of the sprint or iteration, usually a final acceptance meeting takes place, which is typically done by presenting what the team has accomplished, and by delivering a demo to the customer or to a larger audience.
- At the end of an iteration there is also a sprint retro meeting , similar to a postmortem meeting at the end of other traditional projects, so the team gets together to evaluate what worked well, and what needs to be improved during their next iteration.
Top 3 things a QA professional should expect when an organization adopts Agile/Scrum development techniques
Agile and Scrum are really changing the way testing is perceived throughout the project. Testing is not a phase at the end; it really is integrated throughout the entire iteration cycle, and it goes hand in hand with programming tasks. In my experience, when comparing a testing role performed within an agile project, or when using more rigid and formal approaches, I have found that with agile methodologies there is:
- Better communication and more collaboration among QA & development folks Gone are the days of "give me requirements" and "I will give you bugs
|Agile and Scrum methodologies from a testing/QA perspective||31.57 KB|