<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/atom10full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><feed xmlns="http://www.w3.org/2005/Atom" xmlns:openSearch="http://a9.com/-/spec/opensearch/1.1/" xmlns:blogger="http://schemas.google.com/blogger/2008" xmlns:georss="http://www.georss.org/georss" xmlns:gd="http://schemas.google.com/g/2005" xmlns:thr="http://purl.org/syndication/thread/1.0" xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" gd:etag="W/&quot;DUcMQnkycCp7ImA9WhNaE0U.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987</id><updated>2013-01-28T21:01:23.798+05:30</updated><category term="Lean" /><category term="Feature teams" /><category term="continuous integration" /><category term="Component teams" /><category term="Velocity" /><category term="Release" /><category term="process" /><category term="Software Development" /><category term="Acceptance" /><category term="Agile Scrum PMIACP PMI" /><category term="Teams" /><category term="Agile Scrum &quot;Ball Point Game&quot;" /><category term="Release Planning" /><category term="large global teams" /><category term="Coaching" /><category term="communication" /><category term="PMI" /><category term="Unit" /><category term="user stories" /><category term="Testing" /><category term="Stand-ups" /><category term="PMI-ACP" /><category term="Retrospective" /><category term="TDD" /><category term="Burndown" /><category term="Story points" /><category term="build" /><category term="SCMM" /><category term="Agile" /><category term="enterprise" /><category term="Improvements" /><category term="Kanban" /><category term="Scrum" /><category term="scrumbut" /><category term="review board" /><category term="Sprint" /><category term="Agile Testing" /><category term="Story Breakdown" /><category term="Agile Manifesto" /><category term="Planning meeting" /><category term="Planning Poker" /><category term="mockups" /><category term="Automation" /><category term="code review" /><category term="Task Template" /><title>PracticeAgile Solutions Private Limited</title><subtitle type="html">Agile Coaching | Training | Consulting | Assessment</subtitle><link rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml" href="http://www.practiceagile.com/feeds/posts/default" /><link rel="alternate" type="text/html" href="http://www.practiceagile.com/" /><link rel="next" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default?start-index=26&amp;max-results=25&amp;redirect=false&amp;v=2" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><generator version="7.00" uri="http://www.blogger.com">Blogger</generator><openSearch:totalResults>45</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>25</openSearch:itemsPerPage><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/atom+xml" href="http://feeds.feedburner.com/PracticeAgileSoftwareDevelopment" /><feedburner:info uri="practiceagilesoftwaredevelopment" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com/" /><feedburner:emailServiceId>PracticeAgileSoftwareDevelopment</feedburner:emailServiceId><feedburner:feedburnerHostname>http://feedburner.google.com</feedburner:feedburnerHostname><entry gd:etag="W/&quot;DUcMQnY7fip7ImA9WhNaE0U.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-6079216300217297656</id><published>2013-01-26T10:54:00.002+05:30</published><updated>2013-01-28T21:01:23.806+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2013-01-28T21:01:23.806+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Sprint" /><category scheme="http://www.blogger.com/atom/ns#" term="SCMM" /><category scheme="http://www.blogger.com/atom/ns#" term="Release Planning" /><category scheme="http://www.blogger.com/atom/ns#" term="Agile" /><title>Ran my first Half Marathon the Agile way</title><summary type="html">

The Worli Sea Link

On January 20th 2013, I ran and successfully completed my first Standard Chartered Half Marathon in the beautiful city of Mumbai in an Agile way. What an awesome experience it was. 

My skill level with running: Novice,  I had put around 90 km of  a total run in a period of 3 months during training. Just for comparison, average runners put around 100 to 150 km in a month. 

&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/qNdr7P76dG4" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/6079216300217297656?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/6079216300217297656?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/qNdr7P76dG4/ran-my-first-half-marathon-agile-way.html" title="Ran my first Half Marathon the Agile way" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://3.bp.blogspot.com/-Ng20MlhCoAY/UQJ5sfURFJI/AAAAAAAABH0/hNZMtKaRrJM/s72-c/SEALINK1.jpg" height="72" width="72" /><feedburner:origLink>http://www.practiceagile.com/2013/01/ran-my-first-half-marathon-agile-way.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DU8NSHo-fip7ImA9WhNVFko.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-2706718670511155146</id><published>2012-12-28T12:26:00.000+05:30</published><updated>2012-12-28T12:28:19.456+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2012-12-28T12:28:19.456+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Improvements" /><category scheme="http://www.blogger.com/atom/ns#" term="Coaching" /><category scheme="http://www.blogger.com/atom/ns#" term="Retrospective" /><category scheme="http://www.blogger.com/atom/ns#" term="Agile" /><title>Agile Coaching: Are your retrospectives effective? </title><summary type="html">
Are you in a situation where your team(s) has been practicing Agile for a while and teams are following ceremonies meticulously, but still there are no significant improvements sprint over sprint or release after release? If yes, I have some antidotes that I will share through series of blogs that you can experiment with.



One of the Agile principle is, "At regular intervals, the team reflects&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/GaFBDqxcmOo" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/2706718670511155146?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/2706718670511155146?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/GaFBDqxcmOo/agile-coaching-are-your-retrospectives.html" title="Agile Coaching: Are your retrospectives effective? " /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://3.bp.blogspot.com/-h20OTYx2Ink/UN067Q4Yr4I/AAAAAAAABHg/-RIsfXFmE_w/s72-c/retrospective.JPG" height="72" width="72" /><feedburner:origLink>http://www.practiceagile.com/2012/12/agile-coaching-are-your-retrospectives.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DkcDSXoyeSp7ImA9WhNVFk0.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-8850488427734709660</id><published>2012-12-27T15:43:00.000+05:30</published><updated>2012-12-27T15:57:58.491+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2012-12-27T15:57:58.491+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Lean" /><category scheme="http://www.blogger.com/atom/ns#" term="Kanban" /><category scheme="http://www.blogger.com/atom/ns#" term="Scrum" /><category scheme="http://www.blogger.com/atom/ns#" term="Agile" /><title>Tesco's Success Story with Agile Adoption </title><summary type="html">











Over the past 2 years I have been helping Tesco's Dotcom International Grocery Home Shopping (IGHS) group in the capacity of Agile Coach to build their eCommerce Platform. Tesco Dotcom's challenge was to take the world's largest grocery website international to multiple countries outside UK as quickly as possible and be the market leader. 


As the saying goes, "The proof is in the &lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/zuSFfDU9v74" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/8850488427734709660?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/8850488427734709660?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/zuSFfDU9v74/tescos-success-story-with-agile-adoption.html" title="Tesco's Success Story with Agile Adoption " /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://2.bp.blogspot.com/-yHIaCnI9L7A/UNv6TnZAU6I/AAAAAAAABGw/4wI13rKDg2I/s72-c/283.JPG" height="72" width="72" /><feedburner:origLink>http://www.practiceagile.com/2012/12/tescos-success-story-with-agile-adoption.html</feedburner:origLink></entry><entry gd:etag="W/&quot;C0QFRXY8eyp7ImA9WhJQFUs.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-1830265545107366328</id><published>2012-07-29T16:58:00.001+05:30</published><updated>2012-07-29T16:58:34.873+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2012-07-29T16:58:34.873+05:30</app:edited><title>TechGig: How Agile Turns Fragile</title><summary type="html">

&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/z2E9C9mXzZk" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/1830265545107366328?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/1830265545107366328?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/z2E9C9mXzZk/techgig-how-agile-turns-fragile.html" title="TechGig: How Agile Turns Fragile" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2012/07/techgig-how-agile-turns-fragile.html</feedburner:origLink></entry><entry gd:etag="W/&quot;CE4CRXg-eyp7ImA9WhRXEk8.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-2961910946875287148</id><published>2011-12-18T20:48:00.001+05:30</published><updated>2011-12-18T21:12:44.653+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2011-12-18T21:12:44.653+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Agile Scrum &quot;Ball Point Game&quot;" /><title>The Agile Ball Point Game</title><summary type="html">This video demonstrates the Ball point game, a game to feel what it is to work in an Agile team. I facilitated this at PMI West Bengal chapter annual conference Aviskar.

&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/e5T8Z2XCVMc" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/2961910946875287148?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/2961910946875287148?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/e5T8Z2XCVMc/agile-ball-point-game.html" title="The Agile Ball Point Game" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2011/12/agile-ball-point-game.html</feedburner:origLink></entry><entry gd:etag="W/&quot;C04ERns4fyp7ImA9WhRXEk8.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-9009930223033867858</id><published>2011-12-18T15:59:00.001+05:30</published><updated>2011-12-18T20:55:07.537+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2011-12-18T20:55:07.537+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Agile Scrum PMIACP PMI" /><title>Agile talk at PMI Mumbai Conclave 2011</title><summary type="html">At PMI Mumbai Conclave 2011, I gave a talk on "Mitigating Risks with Agile Project Management". I am embedding videos for everyone's reference.



&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/NJABGlOBj2A" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/9009930223033867858?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/9009930223033867858?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/NJABGlOBj2A/agile-talk-at-pmi-mumbai-conclave-2011.html" title="Agile talk at PMI Mumbai Conclave 2011" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2011/12/agile-talk-at-pmi-mumbai-conclave-2011.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DkECRX84cCp7ImA9WhdVFE8.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-1376582609668007984</id><published>2011-09-19T15:01:00.000+05:30</published><updated>2011-09-19T15:01:04.138+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2011-09-19T15:01:04.138+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="PMI-ACP" /><title>PMI Agile Certification: Filling a Gap in Industry (PMI Article: ManageIndia Volume 3 Issue 3)</title><summary type="html">
PMI Agile Certification: Filling a Gap in IndustryThe certification comes at a time when agile practices are gaining ground across IndiaKeep it flexible, keep it agile. Increasingly, organizations are realizing the need to keep their development processes open to change. If the market conditions are dynamic, shouldn’t the product development environment reflect the changing forces at work? With &lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/UTrWEwGr3_M" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/1376582609668007984?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/1376582609668007984?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/UTrWEwGr3_M/pmi-agile-certification-filling-gap-in.html" title="PMI Agile Certification: Filling a Gap in Industry (PMI Article: ManageIndia Volume 3 Issue 3)" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2011/09/pmi-agile-certification-filling-gap-in.html</feedburner:origLink></entry><entry gd:etag="W/&quot;CkECSXwyeCp7ImA9WhdQEEU.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-4601461172733681596</id><published>2011-08-11T22:07:00.000+05:30</published><updated>2011-08-11T22:07:48.290+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2011-08-11T22:07:48.290+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Agile" /><category scheme="http://www.blogger.com/atom/ns#" term="PMI-ACP" /><category scheme="http://www.blogger.com/atom/ns#" term="PMI" /><title>PMI Agile (PMI-ACP) curriculum rocks!</title><summary type="html">
Finally, it’s good to see a solid and complete Agile curriculum. PMI has come up with new certification, PMI-ACP (Agile Certification Program) to test students on their Agile knowledge. PMI’s Agile exam will test student’s knowledge with 120 multi choice questions on all major Agile methodologies like Scrum, XP, Lean Kanban, Crystal, FDD, etc. 
What I find good about this exam is it is not &lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/PV1GhNAvUhU" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/4601461172733681596?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/4601461172733681596?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/PV1GhNAvUhU/pmi-agile-pmi-acp-curriculum-rocks.html" title="PMI Agile (PMI-ACP) curriculum rocks!" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2011/08/pmi-agile-pmi-acp-curriculum-rocks.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DUQESX0-fyp7ImA9WhZQEEg.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-7756741516631149041</id><published>2011-04-17T21:51:00.000+05:30</published><updated>2011-04-17T21:51:48.357+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2011-04-17T21:51:48.357+05:30</app:edited><title>My talk @ SPIN Meet on Structured Agile Project Management Processes</title><summary type="html">CSI SPIN - Mumbai(Software Process Improvement Network)
When: Friday, May 6th 2011 6:00pm to 8:30pm
Venue:CSI  Mumbai ChapterE- 217, 2nd Floor. Floral Deck Plaza, Near Seepz, MIDC, Andheri (E)  Mumbai 400093Ph: +91 22 28235476 / 28235548
We request you to please register at info@csimumbai.org, csimumbai@vsnl.com with cc to the underlined. 
For further details contact:
Mr. R C Goyal, Member IEEE &lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/IGerot2beUg" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/7756741516631149041?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/7756741516631149041?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/IGerot2beUg/my-talk-spin-meet-on-structured-agile.html" title="My talk @ SPIN Meet on Structured Agile Project Management Processes" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2011/04/my-talk-spin-meet-on-structured-agile.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DEYGQ3s4cCp7ImA9Wx5bEU0.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-326106862809025247</id><published>2010-10-26T20:45:00.000+05:30</published><updated>2010-10-26T20:45:22.538+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2010-10-26T20:45:22.538+05:30</app:edited><title>Bay XP Meeting Part 2: Agile Estimation, Mike Cohn</title><summary type="html">&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/3-7WhgzFH3s" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/326106862809025247?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/326106862809025247?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/3-7WhgzFH3s/bay-xp-meeting-part-2-agile-estimation.html" title="Bay XP Meeting Part 2: Agile Estimation, Mike Cohn" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2010/10/bay-xp-meeting-part-2-agile-estimation.html</feedburner:origLink></entry><entry gd:etag="W/&quot;CUIDQH86eip7ImA9Wx5bEU0.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-2539419941764809743</id><published>2010-10-26T20:02:00.000+05:30</published><updated>2010-10-26T20:02:51.112+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2010-10-26T20:02:51.112+05:30</app:edited><title>Bay XP Meeting Part 1: Agile Estimation, Mike Cohn</title><summary type="html">&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/BB40VausgAU" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/2539419941764809743?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/2539419941764809743?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/BB40VausgAU/bay-xp-meeting-part-1-agile-estimation.html" title="Bay XP Meeting Part 1: Agile Estimation, Mike Cohn" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2010/10/bay-xp-meeting-part-1-agile-estimation.html</feedburner:origLink></entry><entry gd:etag="W/&quot;C08DQXs4eSp7ImA9Wx5VE0o.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-1360767155515375456</id><published>2010-10-06T19:01:00.000+05:30</published><updated>2010-10-06T19:01:10.531+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2010-10-06T19:01:10.531+05:30</app:edited><title>The Pentagon Wars - A product management lesson</title><summary type="html">&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/pTxRatmGZfg" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/1360767155515375456?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/1360767155515375456?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/pTxRatmGZfg/pentagon-wars-product-management-lesson.html" title="The Pentagon Wars - A product management lesson" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2010/10/pentagon-wars-product-management-lesson.html</feedburner:origLink></entry><entry gd:etag="W/&quot;CUUNQ3wzfSp7ImA9Wx5VEkg.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-2476247981298655681</id><published>2010-10-05T10:04:00.000+05:30</published><updated>2010-10-05T10:04:52.285+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2010-10-05T10:04:52.285+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Agile Manifesto" /><category scheme="http://www.blogger.com/atom/ns#" term="Agile" /><title>Delivering features based on Business Value</title><summary type="html">Agile software development emphasizes on delivering functionality on highest business value. What this means is, to prioritize the product backlog based on features that are most valuable to the end customers.

I often give this example to new teams transitioning to Agile development. Taking "Microsoft Word" as an example, I ask the team if I consolidate overall functionality in Microsoft Word to&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/w5pEkHOP7so" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/2476247981298655681?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/2476247981298655681?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/w5pEkHOP7so/delivering-features-based-on-business.html" title="Delivering features based on Business Value" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2010/10/delivering-features-based-on-business.html</feedburner:origLink></entry><entry gd:etag="W/&quot;D0QEQXk4eip7ImA9Wx5VEU0.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-3983941204918855044</id><published>2010-10-03T16:58:00.000+05:30</published><updated>2010-10-03T16:58:20.732+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2010-10-03T16:58:20.732+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Automation" /><category scheme="http://www.blogger.com/atom/ns#" term="Acceptance" /><category scheme="http://www.blogger.com/atom/ns#" term="Unit" /><category scheme="http://www.blogger.com/atom/ns#" term="Agile Testing" /><title>Diminishing ROI with NO Automation in Agile development</title><summary type="html">My interaction with various clients that are in process of transitioning to Agile often ask this question - Is it ok to skip automated Unit and Acceptance testing and only perform manual testing? The reservation normally arises due to old school of thought where manual testing was tolerated and where CLIs and API needed for testing are normally an after thought. Sometimes it is also because QA &lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/lPE2daCUddY" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/3983941204918855044?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/3983941204918855044?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/lPE2daCUddY/diminishing-roi-with-no-automation-in.html" title="Diminishing ROI with NO Automation in Agile development" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://4.bp.blogspot.com/_RrcYFKtIaDw/TKhh-hPU97I/AAAAAAAAAkw/mQJoidBQPeo/s72-c/1.jpg" height="72" width="72" /><feedburner:origLink>http://www.practiceagile.com/2010/10/diminishing-roi-with-no-automation-in.html</feedburner:origLink></entry><entry gd:etag="W/&quot;CkcDSHgzcSp7ImA9Wx5QEkk.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-1297979865340652579</id><published>2010-08-31T13:04:00.000+05:30</published><updated>2010-08-31T13:04:39.689+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2010-08-31T13:04:39.689+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="user stories" /><category scheme="http://www.blogger.com/atom/ns#" term="Task Template" /><category scheme="http://www.blogger.com/atom/ns#" term="Story Breakdown" /><title>Template of task breakdown for a user story</title><summary type="html">In a few Agile/Scrum training and coaching engagements that I have been involved with, I shared the template of ‘task breakdown for a user story' and found that teams find it very useful. This task list also defines ‘done’ criteria for the story. I am sharing the same template with everyone in this forum for your reference.
As a rule of thumb, I recommend scrum teams to define a user story that &lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/qZoXQoV8nSI" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/1297979865340652579?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/1297979865340652579?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/qZoXQoV8nSI/template-of-task-breakdown-for-user.html" title="Template of task breakdown for a user story" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2010/08/template-of-task-breakdown-for-user.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DEIARnc4eCp7ImA9WxFbGU8.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-6566527861911037975</id><published>2010-07-12T14:52:00.000+05:30</published><updated>2010-07-12T14:52:27.930+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2010-07-12T14:52:27.930+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Scrum" /><title>Wrong influences on Scrum teams.</title><summary type="html">There is an inherent understanding in Agile implementation that Scrum is all about team and they have a final say on anything that impacts their productivity.  To a certain extent this is true especially if you have only handful of possibly co-located scrum teams. However, in enterprise wide software development where you have dozens of distributed scrum teams external influences will start &lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/7hQJfLHzZuU" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/6566527861911037975?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/6566527861911037975?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/7hQJfLHzZuU/wrong-influences-on-scrum-teams.html" title="Wrong influences on Scrum teams." /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2010/07/wrong-influences-on-scrum-teams.html</feedburner:origLink></entry><entry gd:etag="W/&quot;A0MNR3c5fSp7ImA9WxFUGU0.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-8279496408527396322</id><published>2010-06-30T20:21:00.000+05:30</published><updated>2010-06-30T20:21:36.925+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2010-06-30T20:21:36.925+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Testing" /><category scheme="http://www.blogger.com/atom/ns#" term="TDD" /><title>Test Driven Development (TDD) vs Non TDD approach</title><summary type="html">Recently I had a chat with one of my former colleagues on Test Driven Development (TDD), when he mentioned that writing test code prior to writing production code (TDD) vs writing test code after the code is written should fetch the same results. I disagreed with his statement and to prove my point I gave him following example which seemed to make sense to him and I thought might be worth sharing&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/fo8dj1hI7Nc" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/8279496408527396322?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/8279496408527396322?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/fo8dj1hI7Nc/test-driven-development-tdd-vs-non-tdd.html" title="Test Driven Development (TDD) vs Non TDD approach" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2010/06/test-driven-development-tdd-vs-non-tdd.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DUACR3kyeip7ImA9WxBaEk0.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-539595607183264402</id><published>2010-03-22T03:12:00.000+05:30</published><updated>2010-03-22T03:12:46.792+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2010-03-22T03:12:46.792+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Planning meeting" /><category scheme="http://www.blogger.com/atom/ns#" term="large global teams" /><title>Aligning Scrum Teams - Part 3: - Pulling it all together</title><summary type="html">In the last 2 blogs I discussed the challenges with component based distributed teams and how to overcome those challenges with solid pre-planning. This is the final of the 3 part blogs where I want to discuss how to pull everything together.

Once a solid pre-plan is done, it's time to zero in on the iteration goal a.k.a. the 'Macro' goal (A common goal shared for the iteration by each scrum &lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/HgyVvTd-dXU" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/539595607183264402?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/539595607183264402?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/HgyVvTd-dXU/aligning-scrum-teams-part-3-pulling-it.html" title="Aligning Scrum Teams - Part 3: - Pulling it all together" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2010/03/aligning-scrum-teams-part-3-pulling-it.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DEcDQHk7eyp7ImA9WxBbEUQ.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-2666283372423357050</id><published>2010-03-10T10:11:00.000+05:30</published><updated>2010-03-10T10:11:11.703+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2010-03-10T10:11:11.703+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Planning meeting" /><category scheme="http://www.blogger.com/atom/ns#" term="Component teams" /><title>Aligning Scrum Teams - Part 2: - The Pre-planning</title><summary type="html">The Part 1 blog discussed the challenges one might face with multiple component based scrum teams. In this blog let me discuss a solution to make these enterprise scrums deliver consistent results.
To start with, the team would need a solid pre-planning to put various dots in place before the actual planning happens. It's in fact more than thatDefine goals - This is a big      ticket item and you&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/STGoI4a4Hvs" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/2666283372423357050?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/2666283372423357050?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/STGoI4a4Hvs/aligning-scrum-teams-part-2-pre.html" title="Aligning Scrum Teams - Part 2: - The Pre-planning" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2010/03/aligning-scrum-teams-part-2-pre.html</feedburner:origLink></entry><entry gd:etag="W/&quot;Dk4CRn84fip7ImA9WxBUFko.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-5246439009518279308</id><published>2010-03-04T09:26:00.000+05:30</published><updated>2010-03-04T09:26:07.136+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2010-03-04T09:26:07.136+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Feature teams" /><category scheme="http://www.blogger.com/atom/ns#" term="Planning meeting" /><category scheme="http://www.blogger.com/atom/ns#" term="Component teams" /><title>Aligning Scrum Teams - Part 1:  - The Challenges</title><summary type="html">Let me start this blog with an example - The goal of the next sprint is to deliver integrated functionality of features f1, f2, and f3 by scrum teams s1, s2 and s3. 
If scrums teams are organized as Feature Teams (i.e. Scrum team formed with experienced members from UI, DB, Server, Testing components), it is very easy to divide the work as each team is contained and self sufficient to deliver the&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/Z3q7EHYj6uE" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/5246439009518279308?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/5246439009518279308?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/Z3q7EHYj6uE/aligning-scrum-teams-part-1-challenges.html" title="Aligning Scrum Teams - Part 1:  - The Challenges" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2010/03/aligning-scrum-teams-part-1-challenges.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DUIBQ3c5eip7ImA9WxBVE0o.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-6383216302695958774</id><published>2010-02-17T08:15:00.001+05:30</published><updated>2010-02-17T09:02:32.922+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2010-02-17T09:02:32.922+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Teams" /><category scheme="http://www.blogger.com/atom/ns#" term="Component teams" /><title>Adding new members to a scrum team -- does it Help or Hurt?</title><summary type="html">Consider a scrum team (component teams) operating in a producer-consumer model, catering to requests made by multiple consumers in each sprint. This team, based on their capacity and velocity, can deliver a fixed set of stories in each sprint. Which means that it is going to starve consumers if it cant keep up with their demands. In such circumstances there is a common perception that if more &lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/_RgtnNRfPBw" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/6383216302695958774?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/6383216302695958774?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/_RgtnNRfPBw/adding-new-members-to-scrum-team-does.html" title="Adding new members to a scrum team -- does it Help or Hurt?" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2010/02/adding-new-members-to-scrum-team-does.html</feedburner:origLink></entry><entry gd:etag="W/&quot;CEIBSXs7fyp7ImA9WxBWF0s.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-2013643200661143233</id><published>2010-02-10T06:12:00.000+05:30</published><updated>2010-02-10T06:12:38.507+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2010-02-10T06:12:38.507+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Burndown" /><title>Sprint Burndown says a lot about your scrum team...</title><summary type="html">A Burndown chart is the graphical representation of amount of work left to do (y-axis) versus time (x-axis) and can help get a good heart-beat on how a scrum team is performing.
Some questions that Burndown can help us answer are:How      good is this team with the planning?
How      well is this team executing against the planned stories in a Sprint?
Is      this team self-organized and are they&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/3gYgtI22lBw" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/2013643200661143233?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/2013643200661143233?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/3gYgtI22lBw/sprint-burndown-says-lot-about-your.html" title="Sprint Burndown says a lot about your scrum team..." /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://3.bp.blogspot.com/_RrcYFKtIaDw/S3GvER92hsI/AAAAAAAAAjg/3JnA2_iDwqg/s72-c/burndown.JPG" height="72" width="72" /><feedburner:origLink>http://www.practiceagile.com/2010/02/sprint-burndown-says-lot-about-your.html</feedburner:origLink></entry><entry gd:etag="W/&quot;CEQFRXk5cCp7ImA9WxNbGEg.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-4764451427340967425</id><published>2009-11-22T06:41:00.000+05:30</published><updated>2009-11-22T06:41:54.728+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-11-22T06:41:54.728+05:30</app:edited><title>When should QA be engaged in an iteration?</title><summary type="html">Someone going through my blog recently emailed me a question about when QA should be engaged in an iteration - should it be in the middle of the iteration or should it be at the end of the iteration? I believe the hidden question that the gentleman had was, what can QA accomplish in the very first few days of the iteration, while development is busy designing interfaces and coding to stories?

&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/Aa3U1CR-8-A" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/4764451427340967425?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/4764451427340967425?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/Aa3U1CR-8-A/when-should-qa-be-engaged-in-iteration.html" title="When should QA be engaged in an iteration?" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2009/11/when-should-qa-be-engaged-in-iteration.html</feedburner:origLink></entry><entry gd:etag="W/&quot;D04MSH0-eyp7ImA9WxNUGE8.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-1557139894041901354</id><published>2009-11-10T09:36:00.000+05:30</published><updated>2009-11-10T09:36:29.353+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-11-10T09:36:29.353+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Velocity" /><category scheme="http://www.blogger.com/atom/ns#" term="Planning Poker" /><category scheme="http://www.blogger.com/atom/ns#" term="Story points" /><category scheme="http://www.blogger.com/atom/ns#" term="Release" /><title>Making Release prediction on an Agile Project?</title><summary type="html">Let me show a very easy way of how a release can be predicted using an example.

Let's say, for a particular product under development, there are 5 scrum teams. Each team has special expertise and they contribute to a very specific area of the product i.e. UI, Infra, Security, etc. For this exercise also assume there are 20 epics that need to be developed before the product can be shipped to the &lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/F6Xk0fbJUbw" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/1557139894041901354?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/1557139894041901354?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/F6Xk0fbJUbw/making-release-prediction-on-agile.html" title="Making Release prediction on an Agile Project?" /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2009/11/making-release-prediction-on-agile.html</feedburner:origLink></entry><entry gd:etag="W/&quot;DkcASH87eyp7ImA9WxNUFEo.&quot;"><id>tag:blogger.com,1999:blog-5455059202789512987.post-5806996259867475700</id><published>2009-11-06T07:50:00.000+05:30</published><updated>2009-11-06T07:50:49.103+05:30</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-11-06T07:50:49.103+05:30</app:edited><category scheme="http://www.blogger.com/atom/ns#" term="Retrospective" /><title>Agile Retrospectives...</title><summary type="html">Recently I conducted an iteration Retrospective for one of the Scrum teams which resulted in a good discussion. The feedback helped in making some specific decisions for the team. These decisions had to be communicated to management as this team decided to do things a bit differently than other teams.


One question raised by management was if the Retrospective notes could be shared with everyone&lt;img src="http://feeds.feedburner.com/~r/PracticeAgileSoftwareDevelopment/~4/6zMTTF-yqXo" height="1" width="1"/&gt;</summary><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/5806996259867475700?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/5455059202789512987/posts/default/5806996259867475700?v=2" /><link rel="alternate" type="text/html" href="http://feedproxy.google.com/~r/PracticeAgileSoftwareDevelopment/~3/6zMTTF-yqXo/agile-retrospectives.html" title="Agile Retrospectives..." /><author><name>Hiren Doshi</name><uri>http://www.blogger.com/profile/03602742089942659990</uri><email>noreply@blogger.com</email><gd:image rel="http://schemas.google.com/g/2005#thumbnail" width="32" height="32" src="http://3.bp.blogspot.com/-LxJQZlHgjn4/Tu4Kgrr8ZlI/AAAAAAAAArI/Zwwdj41erS8/s220/hiren.jpg" /></author><feedburner:origLink>http://www.practiceagile.com/2009/11/agile-retrospectives.html</feedburner:origLink></entry></feed>
