Comments on: Scrum – the way I like to do it http://breathingtech.com/2009/scrum-the-way-i-like-to-do-it/ Technology, mobility and software development Wed, 08 Feb 2012 04:34:51 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Mikael http://breathingtech.com/2009/scrum-the-way-i-like-to-do-it/comment-page-1/#comment-4222 Mikael Mon, 08 Mar 2010 07:21:43 +0000 http://breathingtech.com/?p=426#comment-4222 Velocity is quite simple to calculate: Number of total story points / One iteration So if you actually did 25 story points in a sprint (it does not matter how many you actually planed to do). Your velocity for that sprint was 25. Neat and simple :-) Velocity is quite simple to calculate: Number of total story points / One iteration

So if you actually did 25 story points in a sprint (it does not matter how many you actually planed to do). Your velocity for that sprint was 25.

Neat and simple :-)

]]> By: Lita Lemelin http://breathingtech.com/2009/scrum-the-way-i-like-to-do-it/comment-page-1/#comment-3932 Lita Lemelin Mon, 22 Feb 2010 20:23:38 +0000 http://breathingtech.com/?p=426#comment-3932 Our team's practice is that severity is the grade of technical affect while priority is the degree of commercial enterprise impact. The tester may determine an initial value to priority, but in the end the last decision on priority is owned by the business collaborator. Also, we attempt to determine definitions for severity that leave little room for argument, while the definitions for priority are more flexible and responsive to business motivation. Our team’s practice is that severity is the grade of technical affect while priority is the degree of commercial enterprise impact. The tester may determine an initial value to priority, but in the end the last decision on priority is owned by the business collaborator. Also, we attempt to determine definitions for severity that leave little room for argument, while the definitions for priority are more flexible and responsive to business motivation.

]]> By: Including bug fixing in the Scrum sprint http://breathingtech.com/2009/scrum-the-way-i-like-to-do-it/comment-page-1/#comment-978 Including bug fixing in the Scrum sprint Tue, 08 Sep 2009 16:29:04 +0000 http://breathingtech.com/?p=426#comment-978 [...] is a follow up on a post I wrote earlier about how I like to use Scrum and ScrumWorks for my projects. After writing that post I have had some good discussions on how to manage bug [...] [...] is a follow up on a post I wrote earlier about how I like to use Scrum and ScrumWorks for my projects. After writing that post I have had some good discussions on how to manage bug [...]

]]> By: Per Ola Sæther http://breathingtech.com/2009/scrum-the-way-i-like-to-do-it/comment-page-1/#comment-115 Per Ola Sæther Thu, 07 May 2009 10:24:08 +0000 http://breathingtech.com/?p=426#comment-115 Thanx for the link Pål. It's always interesting to learn how other Agile (Scrum) teams do it. JIRA and GreenHopper are interesting but at this moment I feel that ScrumWorks are sufficient for the projects I am involved in. Thanx for the link Pål. It’s always interesting to learn how other Agile (Scrum) teams do it.
JIRA and GreenHopper are interesting but at this moment I feel that ScrumWorks are sufficient for the projects I am involved in.

]]> By: Pål Berg http://breathingtech.com/2009/scrum-the-way-i-like-to-do-it/comment-page-1/#comment-114 Pål Berg Thu, 07 May 2009 06:19:10 +0000 http://breathingtech.com/?p=426#comment-114 I forgot the link :-) Try this http://www.mbricks.no/blog/?p=106 I forgot the link :-) Try this http://www.mbricks.no/blog/?p=106

]]> By: Pål Berg http://breathingtech.com/2009/scrum-the-way-i-like-to-do-it/comment-page-1/#comment-113 Pål Berg Thu, 07 May 2009 06:18:16 +0000 http://breathingtech.com/?p=426#comment-113 Look at this blog Per Ola, this is how we do it at mBricks. We used to use ScrumWorks, but we have now moved to a combination of JIRA and GreenHopper. I think the close integration makes it easier for us to handle the bugs in the Sprint and we "save" the lazy week. Look at this blog Per Ola, this is how we do it at mBricks. We used to use ScrumWorks, but we have now moved to a combination of JIRA and GreenHopper. I think the close integration makes it easier for us to handle the bugs in the Sprint and we “save” the lazy week.

]]> By: Agile Product Management the way we do at mBricks http://breathingtech.com/2009/scrum-the-way-i-like-to-do-it/comment-page-1/#comment-112 Agile Product Management the way we do at mBricks Thu, 07 May 2009 06:01:59 +0000 http://breathingtech.com/?p=426#comment-112 [...] good friend of mine ask how to include bugfixes in the Scrum sprint, Scrum - the way I like to do it. We have also struggled with this at mBricks, the bugfixes always seems to take attention from the [...] [...] good friend of mine ask how to include bugfixes in the Scrum sprint, Scrum – the way I like to do it. We have also struggled with this at mBricks, the bugfixes always seems to take attention from the [...]

]]> By: Per Ola Sæther http://breathingtech.com/2009/scrum-the-way-i-like-to-do-it/comment-page-1/#comment-57 Per Ola Sæther Thu, 23 Apr 2009 09:37:09 +0000 http://breathingtech.com/?p=426#comment-57 Thanks for the tips Laszlos. Quite interesting reading Kane's blog about using spiciness and RSP for estimating story points. I have played a lot of planning poker before to achieve this, maybe I will try RSP the next time. Thanks for the tips Laszlos.
Quite interesting reading Kane’s blog about using spiciness and RSP for estimating story points. I have played a lot of planning poker before to achieve this, maybe I will try RSP the next time.

]]> By: LaszloS http://breathingtech.com/2009/scrum-the-way-i-like-to-do-it/comment-page-1/#comment-56 LaszloS Wed, 22 Apr 2009 22:46:58 +0000 http://breathingtech.com/?p=426#comment-56 Thanks Per Ola Sæther for blogging about Scrum and ScrumWorks. In terms of bugs, just treat them as their own PBIs (product backlog items), and prioritize accordingly. In terms of PBI estimation, I would point you back to Kane's blog. I like his approach which utilizes a spiciness meter - see: http://danube.com/system/files/Story+Points+as+Spiciness+blog.pdf Best of luck with ScrumWorks - we love to hear about success stories, so feel free to drop my team a line anytime. Thanks Per Ola Sæther for blogging about Scrum and ScrumWorks.

In terms of bugs, just treat them as their own PBIs (product backlog items), and prioritize accordingly.

In terms of PBI estimation, I would point you back to Kane’s blog. I like his approach which utilizes a spiciness meter – see: http://danube.com/system/files/Story+Points+as+Spiciness+blog.pdf

Best of luck with ScrumWorks – we love to hear about success stories, so feel free to drop my team a line anytime.

]]> By: Per Ola Sæther http://breathingtech.com/2009/scrum-the-way-i-like-to-do-it/comment-page-1/#comment-55 Per Ola Sæther Tue, 21 Apr 2009 19:09:08 +0000 http://breathingtech.com/?p=426#comment-55 Thank you for the detailed description of your Scrum process. It's always interesting and useful to learn how other Scrum teams organize them selves. I started using effort points in the beginning, but I soon found that we were converting the points to hours (like you said the velocity could be 0.5 points per hour). Now I'm using hours as velocity. I know this is not by the book... but it works good for me so that's my preferred way to do it. We often calculate 6 hours of actual work done during a day, although this differ from team member to team member. Realistic estimates and commitment in the sprints are for sure on of the keys to success. The nice result of running short sprint is that if you have committed too many hours or the estimates are blown away it's easy to adjust this for the next sprint. Learning by doing :) In my opinion ScrumWorks is good enough to totally replace the tablet, but that's my opinion. I guess that it has a lot to do with what your are used too and for sure it takes some time to adapt from tablet to digital tools. When that is said I can't see any problems by running ScrumWorks and tablet side by side. In the end the most important are the processes and not how you visualize them. Thank you for the detailed description of your Scrum process. It’s always interesting and useful to learn how other Scrum teams organize them selves.

I started using effort points in the beginning, but I soon found that we were converting the points to hours (like you said the velocity could be 0.5 points per hour). Now I’m using hours as velocity. I know this is not by the book… but it works good for me so that’s my preferred way to do it. We often calculate 6 hours of actual work done during a day, although this differ from team member to team member.

Realistic estimates and commitment in the sprints are for sure on of the keys to success. The nice result of running short sprint is that if you have committed too many hours or the estimates are blown away it’s easy to adjust this for the next sprint. Learning by doing :)

In my opinion ScrumWorks is good enough to totally replace the tablet, but that’s my opinion. I guess that it has a lot to do with what your are used too and for sure it takes some time to adapt from tablet to digital tools. When that is said I can’t see any problems by running ScrumWorks and tablet side by side. In the end the most important are the processes and not how you visualize them.

]]>