Comments on: Implementing SCRUM…the basics – part 2 http://pmstudent.com/implementing-scrum-the-basics-part-2/ Helping new and aspiring project managers reach their career goals! Sun, 20 May 2012 01:38:56 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Chaos and SCRUM http://pmstudent.com/implementing-scrum-the-basics-part-2/#comment-45239 Chaos and SCRUM Sun, 12 Jun 2011 13:22:13 +0000 http://pmstudent.com/?p=1447#comment-45239 [...] we do the classic planning poker estimating that I described here and then, based upon our standing team velocity we let the Product Owner how much of the backlog we [...] [...] we do the classic planning poker estimating that I described here and then, based upon our standing team velocity we let the Product Owner how much of the backlog we [...]

]]> By: ProjectInsight (Project Insight) http://pmstudent.com/implementing-scrum-the-basics-part-2/#comment-21079 ProjectInsight (Project Insight) Tue, 09 Feb 2010 18:07:53 +0000 http://pmstudent.com/?p=1447#comment-21079 <strong>Twitter Comment</strong> <a href="http://twitter.com/ProjectInsight" title="Twitter Comment" rel="nofollow"> <div class="ccimg1" title="ProjectInsight (Project Insight)" style="float:left;margin-right:10px;padding:0;width:60px;height:60px;background:url(http://pmstudent.com/wp-content/plugins/chatcatcher/picbg.jpg) no-repeat top;cursor:hand;"> </div> <div class="ccimg2" title="ProjectInsight (Project Insight)" style="float:left;margin-left:-70px;margin-right:10px;padding:0;width:60px;height:60px;background:url(http://purl.org/net/spiurl/ProjectInsight) no-repeat top;cursor:hand;"> </div> </a> RT @pmstudent: #PMOT Comment on Implementing SCRUM…the basics – part 2 by alohafromSF (alohafromSF) [link to post]<br /><br /> - <a href="http://chatcatcher.com" target="_blank" rel="nofollow">Posted using Chat Catcher</a> Twitter Comment


RT @pmstudent: #PMOT Comment on Implementing SCRUM…the basics – part 2 by alohafromSF (alohafromSF) [link to post]

– Posted using Chat Catcher

]]> By: Josh Nankivel, BSc PM, PMP http://pmstudent.com/implementing-scrum-the-basics-part-2/#comment-21078 Josh Nankivel, BSc PM, PMP Tue, 09 Feb 2010 17:48:52 +0000 http://pmstudent.com/?p=1447#comment-21078 Thanks Jim. Now THAT would be an interesting post, to hear about the challenges of juggling different products, owners, etc. from sprint to sprint. I'm used to 1 product per team through multiple iterations until the final release is delivered, and then moving on to another product. Thanks Jim. Now THAT would be an interesting post, to hear about the challenges of juggling different products, owners, etc. from sprint to sprint.

I’m used to 1 product per team through multiple iterations until the final release is delivered, and then moving on to another product.

]]> By: Josh Nankivel, BSc PM, PMP http://pmstudent.com/implementing-scrum-the-basics-part-2/#comment-24644 Josh Nankivel, BSc PM, PMP Tue, 09 Feb 2010 17:48:00 +0000 http://pmstudent.com/?p=1447#comment-24644 Thanks Jim. Now THAT would be an interesting post, to hear about the challenges of juggling different products, owners, etc. from sprint to sprint. I'm used to 1 product per team through multiple iterations until the final release is delivered, and then moving on to another product. Thanks Jim. Now THAT would be an interesting post, to hear about the challenges of juggling different products, owners, etc. from sprint to sprint.

I’m used to 1 product per team through multiple iterations until the final release is delivered, and then moving on to another product.

]]> By: Jim Kinter http://pmstudent.com/implementing-scrum-the-basics-part-2/#comment-21076 Jim Kinter Tue, 09 Feb 2010 17:08:30 +0000 http://pmstudent.com/?p=1447#comment-21076 You're right Josh. We do short two week sprints and use the same core team every time in order to accomplish this. The challenge in our situation is that it's not uncommon for every sprint to be addressing a different product/product owner/testing & QA regimen. Juggling backlogs, herding product owners, training product owners, and making sure that testing/QA/Documentation are happening appropriately within the sprint are challenges to be sure. In our fluid and dynamic environment, solving problems iteratively and incrementally has made a tremendous positive impact on developer morale as well as in the quality and timeliness of the solutions delivered. In my opinion, the fundamental benefit of SCRUM is the simple fact that we can delegate responsibility for prioritizing what is delivered back onto the business. This is significantly different than it used to be with BDUF/Waterfall when we would get loose requirements thrown at us, a corresponding schedule, and a "whatever it takes" mandate. Now we can provide a sustainable pace of consistently delivering functionality in small operational deliverables and we have the "requirements slingers" sitting on the team with us. Manage the variability between sprints, make sure that your "pigs" are "pigs" and your "chickens" are "chickens", ensure that the team is empowered to do whatever is necessary to deliver on what they have committed to deliver, and firewall them from whatever distractions might impact those committments and your potential for success improves. You’re right Josh. We do short two week sprints and use the same core team every time in order to accomplish this. The challenge in our situation is that it’s not uncommon for every sprint to be addressing a different product/product owner/testing & QA regimen. Juggling backlogs, herding product owners, training product owners, and making sure that testing/QA/Documentation are happening appropriately within the sprint are challenges to be sure. In our fluid and dynamic environment, solving problems iteratively and incrementally has made a tremendous positive impact on developer morale as well as in the quality and timeliness of the solutions delivered. In my opinion, the fundamental benefit of SCRUM is the simple fact that we can delegate responsibility for prioritizing what is delivered back onto the business. This is significantly different than it used to be with BDUF/Waterfall when we would get loose requirements thrown at us, a corresponding schedule, and a “whatever it takes” mandate. Now we can provide a sustainable pace of consistently delivering functionality in small operational deliverables and we have the “requirements slingers” sitting on the team with us. Manage the variability between sprints, make sure that your “pigs” are “pigs” and your “chickens” are “chickens”, ensure that the team is empowered to do whatever is necessary to deliver on what they have committed to deliver, and firewall them from whatever distractions might impact those committments and your potential for success improves.

]]> By: Jim Kinter http://pmstudent.com/implementing-scrum-the-basics-part-2/#comment-24643 Jim Kinter Tue, 09 Feb 2010 17:08:00 +0000 http://pmstudent.com/?p=1447#comment-24643 You're right Josh. We do short two week sprints and use the same core team every time in order to accomplish this. The challenge in our situation is that it's not uncommon for every sprint to be addressing a different product/product owner/testing & QA regimen. Juggling backlogs, herding product owners, training product owners, and making sure that testing/QA/Documentation are happening appropriately within the sprint are challenges to be sure. In our fluid and dynamic environment, solving problems iteratively and incrementally has made a tremendous positive impact on developer morale as well as in the quality and timeliness of the solutions delivered. In my opinion, the fundamental benefit of SCRUM is the simple fact that we can delegate responsibility for prioritizing what is delivered back onto the business. This is significantly different than it used to be with BDUF/Waterfall when we would get loose requirements thrown at us, a corresponding schedule, and a "whatever it takes" mandate. Now we can provide a sustainable pace of consistently delivering functionality in small operational deliverables and we have the "requirements slingers" sitting on the team with us. Manage the variability between sprints, make sure that your "pigs" are "pigs" and your "chickens" are "chickens", ensure that the team is empowered to do whatever is necessary to deliver on what they have committed to deliver, and firewall them from whatever distractions might impact those committments and your potential for success improves. You’re right Josh. We do short two week sprints and use the same core team every time in order to accomplish this. The challenge in our situation is that it’s not uncommon for every sprint to be addressing a different product/product owner/testing & QA regimen. Juggling backlogs, herding product owners, training product owners, and making sure that testing/QA/Documentation are happening appropriately within the sprint are challenges to be sure. In our fluid and dynamic environment, solving problems iteratively and incrementally has made a tremendous positive impact on developer morale as well as in the quality and timeliness of the solutions delivered. In my opinion, the fundamental benefit of SCRUM is the simple fact that we can delegate responsibility for prioritizing what is delivered back onto the business. This is significantly different than it used to be with BDUF/Waterfall when we would get loose requirements thrown at us, a corresponding schedule, and a “whatever it takes” mandate. Now we can provide a sustainable pace of consistently delivering functionality in small operational deliverables and we have the “requirements slingers” sitting on the team with us. Manage the variability between sprints, make sure that your “pigs” are “pigs” and your “chickens” are “chickens”, ensure that the team is empowered to do whatever is necessary to deliver on what they have committed to deliver, and firewall them from whatever distractions might impact those committments and your potential for success improves.

]]>