tag:blogger.com,1999:blog-53359185749574001462011-07-29T02:35:39.669-07:00Emilia Breton-Lakehttp://www.blogger.com/profile/04870280318414590394noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-5335918574957400146.post-91344423947455317702010-02-18T13:25:00.001-08:002010-02-18T14:45:53.028-08:002010-02-18T14:45:53.028-08:00One of the hot topics lately is how do you account for QA within the framework of Scrum. In my experience we have tried 2 methods the "task" method and the "state" method. Since every team is different I think it is worth metioning both.<br /><br />The first is the state method which borrows slightly from Kanban. In the simplest terms you add a column to your SCRUM board to represent the "IN TEST" state. Once the developer is done with a task it moves from the "IN PROGRESS" state into the "IN TEST" state. Once the task has passed all of the needed tests it moves to the "COMPLETE" state.<br /><br />Next is the task method which falls into your traditional SCRUM. All of the QA tasks (Write test cases, build automated tests, test, etc.) are added to the task list and they flow through the standard SCRUM board states.<br /><br />I have had the most luck with the "task" method because it allows you to see the various Qa tasks with as much clarity as the programing tasks. This also alerts you to any bottel necks that could pop up.<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/5335918574957400146-9134442394745531770?l=blog.scrumpen.com' alt='' /></div><img src="http://feeds.feedburner.com/~r/ScrumPen/~4/TKuIBH7u-V4" height="1" width="1"/>Emilia Breton-Lakehttp://www.blogger.com/profile/04870280318414590394noreply@blogger.com0http://blog.scrumpen.com/2010/02/testing.htmltag:blogger.com,1999:blog-5335918574957400146.post-69528341118972221102010-02-18T13:23:00.001-08:002010-02-18T13:23:36.426-08:002010-02-18T13:23:36.426-08:00Getting Buy In <br />One of the most difficult parts of implementing scrum is getting buy in from all the necessary groups. In every organization the path is different, and the obstacles are unique. However, the first steps are the same in almost every organization.<br /><br />1. Know your Audience<br />A. Tailor your message to their needs, and concerns<br /><br />2. Explain your situation<br />A. Your current process/ methodology<br />B. Any issues, problems, or inefficiencies<br /><br />3. Explain the benefits of Scrum<br />A. Link to your current situation<br /><br />4. Explain Scrum <br /><br />5. Be upfront about the challenges of Scrum<br />A. Make sure to address company specific, cultural and infrastructure challenges<br /><br />Resources<br /><br />Moving to Scrum: Making the Case to Management, Doug Tillman, http://www.devx.com/enterprise/Article/33807/1954?pf=true, 2007<br /><br />Explaining Scrum to Your Management Team, Pete Deemer and Gabrielle Benefield, http://www.goodagile.com/resources/goodagile_managers_presentation.pdf, 2008<br /><br />Scrum Master : Ken Schwaber’s Top Tips, Ken Schwaber, http://www.scrum-master.com/toptips/flash.html, 2005<br /><br />What is SCRUM?, Marc Clifton and J. Dunlap, http://www.codeproject.com/KB/architecture/scrum.aspx#SCRUMValues1 , 2003<br /><br />Redistributable Intro to Scrum, Mike Cohn, www.mountaingoatsoftware.com , 2008<br /><br />Unit testing, http://www.xprogramming.com/software.htm , 2008<div class="blogger-post-footer"><img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/5335918574957400146-6952834111897222110?l=blog.scrumpen.com' alt='' /></div><img src="http://feeds.feedburner.com/~r/ScrumPen/~4/B68yBgFpi5I" height="1" width="1"/>Emilia Breton-Lakehttp://www.blogger.com/profile/04870280318414590394noreply@blogger.com0http://blog.scrumpen.com/2010/02/getting-buy-in.html