Comments on: Mix the Sizes of the Product Backlog Items You Commit To http://blog.mountaingoatsoftware.com/mix-the-sizes-of-the-product-backlog-items-you-commit-to Succeeding With Agile® Fri, 10 Feb 2012 03:51:54 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Mike Cohn http://blog.mountaingoatsoftware.com/mix-the-sizes-of-the-product-backlog-items-you-commit-to/comment-page-1#comment-90605 Mike Cohn Sun, 22 Aug 2010 02:34:16 +0000 http://blog.mountaingoatsoftware.com/?p=479#comment-90605 Hi Thorbjørn-- I'm pleased to hear you are trying out user stories. I think after a few initial hurdles you'll find them a good technique. You are correct that we don't want to create separate user stories for the different layers of work (e.g., UI, business logic, etc.). One possibility for you might be to write smaller stories. If you had a smaller story (that was still worked on by the 3 individuals you list) then it would move more quickly from an "in process" to "done" state. Another option, and possibly a better fit from what I can infer from your comment, would be to create specific tasks representing the work of the user story. During sprint planning the team usually takes the one user story and turns it into perhaps 5-10 tasks. If you had a tasks of "Code the UI" and "Create business logic" and "integrate with third party" and "design tests" and "automate tests" that would probably create the right result for you. You can see this visually a bit at http://www.mountaingoatsoftware.com/scrum/task-boards which shows some task boards. Each row represents a user story and the card in the first column is a user story. Cards in other columns are each tasks. Hi Thorbjørn–
I’m pleased to hear you are trying out user stories. I think after a few initial hurdles you’ll find them a good technique.

You are correct that we don’t want to create separate user stories for the different layers of work (e.g., UI, business logic, etc.). One possibility for you might be to write smaller stories. If you had a smaller story (that was still worked on by the 3 individuals you list) then it would move more quickly from an “in process” to “done” state.

Another option, and possibly a better fit from what I can infer from your comment, would be to create specific tasks representing the work of the user story. During sprint planning the team usually takes the one user story and turns it into perhaps 5-10 tasks. If you had a tasks of “Code the UI” and “Create business logic” and “integrate with third party” and “design tests” and “automate tests” that would probably create the right result for you.

You can see this visually a bit at http://www.mountaingoatsoftware.com/scrum/task-boards which shows some task boards. Each row represents a user story and the card in the first column is a user story. Cards in other columns are each tasks.

]]> By: Thorbjørn Sigberg http://blog.mountaingoatsoftware.com/mix-the-sizes-of-the-product-backlog-items-you-commit-to/comment-page-1#comment-90284 Thorbjørn Sigberg Fri, 20 Aug 2010 11:21:05 +0000 http://blog.mountaingoatsoftware.com/?p=479#comment-90284 We have just adopted user stories, but have some difficulty with the fact that we have two and sometimes three different coders involved in getting one story done. (one UI developer, one business logic developer and one that is focuing on integration against some third party). I've gathered that it is bad practice to split a story horizontally between technical layers, so even though I have three guys this should all be one story. How do you go about passing this story between the developers? We experiment with a kanban board, so even though there is handover between three developers, the story basically stays in the "work" column. Should we just switch names on the task as the underlaying layer is done and the next guy starts working? Usually everyone are to some extent working on the same task at the same time on different layers. Most any examples I find seem to imply that one user story is worked on by one "developer" not taking into account that it may span across layer where no one developer have the required knowledge to complete it. Any comments appreciated. We have just adopted user stories, but have some difficulty with the fact that we have two and sometimes three different coders involved in getting one story done. (one UI developer, one business logic developer and one that is focuing on integration against some third party). I’ve gathered that it is bad practice to split a story horizontally between technical layers, so even though I have three guys this should all be one story. How do you go about passing this story between the developers? We experiment with a kanban board, so even though there is handover between three developers, the story basically stays in the “work” column. Should we just switch names on the task as the underlaying layer is done and the next guy starts working? Usually everyone are to some extent working on the same task at the same time on different layers. Most any examples I find seem to imply that one user story is worked on by one “developer” not taking into account that it may span across layer where no one developer have the required knowledge to complete it.

Any comments appreciated.

]]> By: Podcast #3 – Retrospectiva dos 6 Chapéus « Blog da Bluesoft http://blog.mountaingoatsoftware.com/mix-the-sizes-of-the-product-backlog-items-you-commit-to/comment-page-1#comment-63609 Podcast #3 – Retrospectiva dos 6 Chapéus « Blog da Bluesoft Thu, 07 Jan 2010 23:15:07 +0000 http://blog.mountaingoatsoftware.com/?p=479#comment-63609 [...] Mix the Sizes of the Product Backlog Items You Commit To [...] [...] Mix the Sizes of the Product Backlog Items You Commit To [...]

]]> By: Scheduling stories to avoid hangover « RobGodfrey.net http://blog.mountaingoatsoftware.com/mix-the-sizes-of-the-product-backlog-items-you-commit-to/comment-page-1#comment-63334 Scheduling stories to avoid hangover « RobGodfrey.net Mon, 04 Jan 2010 17:39:43 +0000 http://blog.mountaingoatsoftware.com/?p=479#comment-63334 [...] Cohns post prompted me to blog on what my team has been practicing for the last few [...] [...] Cohns post prompted me to blog on what my team has been practicing for the last few [...]

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/mix-the-sizes-of-the-product-backlog-items-you-commit-to/comment-page-1#comment-63330 Mike Cohn Mon, 04 Jan 2010 16:37:36 +0000 http://blog.mountaingoatsoftware.com/?p=479#comment-63330 Hi Rob-- Good point. You are very right that it will often be much easier for a team to find a way to fit a couple of small stories in on the last day or two. Hi Rob–
Good point. You are very right that it will often be much easier for a team to find a way to fit a couple of small stories in on the last day or two.

]]> By: Rob Godfrey http://blog.mountaingoatsoftware.com/mix-the-sizes-of-the-product-backlog-items-you-commit-to/comment-page-1#comment-63318 Rob Godfrey Mon, 04 Jan 2010 13:56:14 +0000 http://blog.mountaingoatsoftware.com/?p=479#comment-63318 My team have recently started to apply this in practice and play stories in order from biggest to smallest. The larger stories are played first with smaller filler stories deferred towards the end. It's particularly useful when a story starts slipping and you need the rest of the team to pick up the slack. Playing a number of small stories in the last day or two of the iteration is usually manageable across multiple pairs, whereas playing a single larger story generally isn't, or at the very least you need to split the story across pairs which can be painful. My team have recently started to apply this in practice and play stories in order from biggest to smallest. The larger stories are played first with smaller filler stories deferred towards the end.

It’s particularly useful when a story starts slipping and you need the rest of the team to pick up the slack. Playing a number of small stories in the last day or two of the iteration is usually manageable across multiple pairs, whereas playing a single larger story generally isn’t, or at the very least you need to split the story across pairs which can be painful.

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/mix-the-sizes-of-the-product-backlog-items-you-commit-to/comment-page-1#comment-62919 Mike Cohn Thu, 31 Dec 2009 15:31:17 +0000 http://blog.mountaingoatsoftware.com/?p=479#comment-62919 Hi Steve-- Great comparison to the rocks in a jar story. I've heard that story numerous times and never related it to this. Now that you point it out, it's very clear. Thanks. Hi Steve–
Great comparison to the rocks in a jar story. I’ve heard that story numerous times and never related it to this. Now that you point it out, it’s very clear. Thanks.

]]> By: Steve Bohlen http://blog.mountaingoatsoftware.com/mix-the-sizes-of-the-product-backlog-items-you-commit-to/comment-page-1#comment-62918 Steve Bohlen Thu, 31 Dec 2009 15:24:50 +0000 http://blog.mountaingoatsoftware.com/?p=479#comment-62918 This seems (conceptually) similar to the old 'trick' of starting with a jar full of rocks that seems 'full', then pouring in smaller gravel that demonstrates how its possible to fill the jar more completely, then repeating the process with finer-grained sand, then finally with water -- all demonstrating that even when something seems 'full' there is often in fact still room for more, assuming the 'more' is small enough to fit into the gaps between the larger items already present. By selecting variable-sized stories for an iteration, this seems a similar concepts applied to workload allocation (fill the small gaps between larger tasks with smaller tasks that fit the gaps well). Great idea(s)! -Steve B. This seems (conceptually) similar to the old ‘trick’ of starting with a jar full of rocks that seems ‘full’, then pouring in smaller gravel that demonstrates how its possible to fill the jar more completely, then repeating the process with finer-grained sand, then finally with water — all demonstrating that even when something seems ‘full’ there is often in fact still room for more, assuming the ‘more’ is small enough to fit into the gaps between the larger items already present.

By selecting variable-sized stories for an iteration, this seems a similar concepts applied to workload allocation (fill the small gaps between larger tasks with smaller tasks that fit the gaps well).

Great idea(s)!

-Steve B.

]]> By: Sameh http://blog.mountaingoatsoftware.com/mix-the-sizes-of-the-product-backlog-items-you-commit-to/comment-page-1#comment-62891 Sameh Thu, 31 Dec 2009 05:26:58 +0000 http://blog.mountaingoatsoftware.com/?p=479#comment-62891 Yes, I understand that it is best to have all team working on the same user-stories at the same sprint. This will reduce work-in-progress that tends to lengthen the lead-time to implement a feature. My reservation is that testing of working code is different kind of skills with different mind-set. By testing, I don't mean the unit-testing that should be completed by developers, I mean QA activities which can only be executed once the code has been unit tested and integrated by developers. Till it comes the time we have testing is done on sample of code (as the case with other industries), testing will continue to be challenging. From my experience, testing and associated code fixing take more than 50% of the development effort. If testers follow professional approach for developing test cases during their involvements with the analysts and designers, this probably can reduce their waiting time. Also, the reusable test cases are valuable assets for re-running the testing at future sprints as new features are added. If testers (QA) are more doing exploratory testing without producing test plan and procedures; then they are bound to wait. Yes, I understand that it is best to have all team working on the same user-stories at the same sprint. This will reduce work-in-progress that tends to lengthen the lead-time to implement a feature.

My reservation is that testing of working code is different kind of skills with different mind-set. By testing, I don’t mean the unit-testing that should be completed by developers, I mean QA activities which can only be executed once the code has been unit tested and integrated by developers.

Till it comes the time we have testing is done on sample of code (as the case with other industries), testing will continue to be challenging. From my experience, testing and associated code fixing take more than 50% of the development effort. If testers follow professional approach for developing test cases during their involvements with the analysts and designers, this probably can reduce their waiting time. Also, the reusable test cases are valuable assets for re-running the testing at future sprints as new features are added.

If testers (QA) are more doing exploratory testing without producing test plan and procedures; then they are bound to wait.

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/mix-the-sizes-of-the-product-backlog-items-you-commit-to/comment-page-1#comment-62870 Mike Cohn Wed, 30 Dec 2009 23:30:32 +0000 http://blog.mountaingoatsoftware.com/?p=479#comment-62870 Hi Sameh-- If I understand you correctly, you're describing having the testers (for example) following a partial sprint behind. I certainly experimented with that back in the mid-90s when I began taking an agile approach to projects. But what I (and just about everyone else) learned is that this is a bad idea. There are too many reasons why for me to go into right now (but hopefully others can contribute some). However, I'll mention that Scrum gets its very name from the idea of a cross-functional team working all together during the sprint/iteration. Hi Sameh–
If I understand you correctly, you’re describing having the testers (for example) following a partial sprint behind. I certainly experimented with that back in the mid-90s when I began taking an agile approach to projects. But what I (and just about everyone else) learned is that this is a bad idea. There are too many reasons why for me to go into right now (but hopefully others can contribute some). However, I’ll mention that Scrum gets its very name from the idea of a cross-functional team working all together during the sprint/iteration.

]]>