Comments on: QA and Agile http://agilemethodology.org/qa-and-agile/ Understanding Agile Methodology Wed, 04 Jan 2012 09:02:21 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: admin http://agilemethodology.org/qa-and-agile/comment-page-1/#comment-2511 admin Fri, 21 Aug 2009 17:53:40 +0000 http://agilemethodology.org/?p=50#comment-2511 Thanks for your comments James. Scope can be tracked within the Enhanced Burndown Chart and if you feel like you're getting trampled, I would suggest tracking your velocity and using velocity as one of the guides to help with sprint planning / negotiations with the Product Owner. Learning to push back on a product owner during the planning meeting can be hard. I would recommend this article over at Agile Journal as further reading (http://www.agilejournal.com/articles/columns/column-articles/1915-how-scrum-generates-increased-productivity-part-three-the-team) Quality should never be used as a lever. I would suggest reading this article on technical debt- ( http://www.danube.com/blog/kanemar/technical_debt_and_the_death_of_design_part_1.html) Part two and three are available from the danube page as well. Disagree with your last statement. Sprint planning should be done - my feelings are: (a) Your PO is estimating your backlog - try having your team estimate your backlog (b) Your requirements aren't written with good user stories with clear acceptance criterias outlined (Definition of Done) I'd recommend this blog from Michael James for further reading on that: http://www.danube.com/blog/michaeljames/user_story_examples_and_counterexamples Thanks for your comments James. Scope can be tracked within the Enhanced Burndown Chart and if you feel like you’re getting trampled, I would suggest tracking your velocity and using velocity as one of the guides to help with sprint planning / negotiations with the Product Owner.

Learning to push back on a product owner during the planning meeting can be hard. I would recommend this article over at Agile Journal as further reading (http://www.agilejournal.com/articles/columns/column-articles/1915-how-scrum-generates-increased-productivity-part-three-the-team)

Quality should never be used as a lever. I would suggest reading this article on technical debt- ( http://www.danube.com/blog/kanemar/technical_debt_and_the_death_of_design_part_1.html)

Part two and three are available from the danube page as well.

Disagree with your last statement. Sprint planning should be done – my feelings are:
(a) Your PO is estimating your backlog – try having your team estimate your backlog
(b) Your requirements aren’t written with good user stories with clear acceptance criterias outlined (Definition of Done)

I’d recommend this blog from Michael James for further reading on that: http://www.danube.com/blog/michaeljames/user_story_examples_and_counterexamples

]]> By: James K http://agilemethodology.org/qa-and-agile/comment-page-1/#comment-1836 James K Tue, 02 Jun 2009 16:41:19 +0000 http://agilemethodology.org/?p=50#comment-1836 One thing I'd like to see more of when agile or scrum is discussed is the need to change the requirements based on the resources or the resources based on the requirements. Also I'd like to see more discussion on scope. QA can easily get trampled in the agile/scrum process in my experience or QA can cheat and not adequately test something and the developer isn't paying attention enough to notice and everyone is "suprised" near the end of the sprint by the problems. Sprint planning seems to be the most important part of the process, but it often seems the assumption is you just plan and adapt and everything will work out. I'd like to see more organizations dissolve their sprints and restart more often rather than grinding on a bad sprint plan. One thing I’d like to see more of when agile or scrum is discussed is the need to change the requirements based on the resources or the resources based on the requirements. Also I’d like to see more discussion on scope.

QA can easily get trampled in the agile/scrum process in my experience or QA can cheat and not adequately test something and the developer isn’t paying attention enough to notice and everyone is “suprised” near the end of the sprint by the problems.

Sprint planning seems to be the most important part of the process, but it often seems the assumption is you just plan and adapt and everything will work out. I’d like to see more organizations dissolve their sprints and restart more often rather than grinding on a bad sprint plan.

]]>