User Tools

Site Tools


how_is_work_assigned_during_a_sprint

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
how_is_work_assigned_during_a_sprint [2020/06/10 12:52] – ↷ Page moved from blog:how_is_work_assigned_during_a_sprint to how_is_work_assigned_during_a_sprint hanshow_is_work_assigned_during_a_sprint [2022/08/15 09:30] (current) – Removed Jira Sub-task reference hans
Line 1: Line 1:
-====== How is Work Assigned During Sprint? ======+====== How is Work Assigned During an Iteration (Sprint)? ======
  
-Sometime old habits and thinking die hard.+Sometime old habits and thinking die hard.
  
 One of the fundamental tenants of Scrum and Agile is that the people who are doing the work are in the best position to make decisions about that work. This differs from a more traditional management approach which says that an outside expert can make better decisions about doing work than the people that are doing the work. The traditional approach is a left over from "[[http://en.wikipedia.org/wiki/Scientific_management|scientific management]]" (or Taylor-ism) a theory of optimizing labor effort which was developed in the 1910's. With scientific management an expert in work process would design a work process based by breaking down each and every task to its simplest constituent, one that required very little training and could be done over and over again by a relatively uneducated workforce. The management expert would then optimize each of these work bits by observing the way it actually worked, timing the process steps and changing the process as a result of what was seen. This approach made sense in the 1900's when companies like Ford were trying to figure out how to mass produce cars using labor that was relatively uneducated (most of the available people were people that moved in from farms to the city) and when you really could slice the jobs down into small repeatable jobs. One of the fundamental tenants of Scrum and Agile is that the people who are doing the work are in the best position to make decisions about that work. This differs from a more traditional management approach which says that an outside expert can make better decisions about doing work than the people that are doing the work. The traditional approach is a left over from "[[http://en.wikipedia.org/wiki/Scientific_management|scientific management]]" (or Taylor-ism) a theory of optimizing labor effort which was developed in the 1910's. With scientific management an expert in work process would design a work process based by breaking down each and every task to its simplest constituent, one that required very little training and could be done over and over again by a relatively uneducated workforce. The management expert would then optimize each of these work bits by observing the way it actually worked, timing the process steps and changing the process as a result of what was seen. This approach made sense in the 1900's when companies like Ford were trying to figure out how to mass produce cars using labor that was relatively uneducated (most of the available people were people that moved in from farms to the city) and when you really could slice the jobs down into small repeatable jobs.
Line 7: Line 7:
 There was a time when we managed software in a similar way, or at least we'd try to. We'd try to break down jobs into small pieces and then assign that work to people for action. In extreme cases we tried to even predict what those tasks were going to be months or even years in advance. And sometimes you still hear of "management" thinking this is the best way to organize work. But while the approach might make sense for a simple, focused job, it does not make sense for software development (or any other knowledge management job, for that matter). You probably understand this intuitively yourself. Remember the time when the manager told you to do something, or do it in a particular way and you absolutely knew that it made no sense for you to do the job (eg because of other jobs you had) or in that way. There was a time when we managed software in a similar way, or at least we'd try to. We'd try to break down jobs into small pieces and then assign that work to people for action. In extreme cases we tried to even predict what those tasks were going to be months or even years in advance. And sometimes you still hear of "management" thinking this is the best way to organize work. But while the approach might make sense for a simple, focused job, it does not make sense for software development (or any other knowledge management job, for that matter). You probably understand this intuitively yourself. Remember the time when the manager told you to do something, or do it in a particular way and you absolutely knew that it made no sense for you to do the job (eg because of other jobs you had) or in that way.
  
-With Scrum we say the team is "self-managed". This means we (or perhaps more accurately, the Product Owner) decides "what" we want (in terms of goals and requirements) and we leave it up to the team to decide "how" they are going to meet the goal. Most teams do not (pre-)assign stories and (sub-)tasks. During the Daily Scrum meeting, as each team member talks about her work, they select the work that will help the team meet the goal of the Sprint. This usually means picking up a (sub-)task on the highest priority story since this maximizes the value delivered and the reduces the risk of meeting the goal of the Sprint. It also helps broaden the team members understanding of the work as while they may not be the expert in the area represented by the task, they will learn something as they do the work. In general it is good to have these more flexible team members as it creates a team which is better able to deal with any requirement thrown at them, increasing the overall value of the team.+With Scrum we say the team is "self-managed". This means we (or perhaps more accurately, the Product Owner) decides "what" we want (in terms of goals and requirements) and we leave it up to the team to decide "how" they are going to meet the goal. Most teams do not (pre-)assign stories. During the Daily Scrum meeting, as each team member talks about her work, they select the work that will help the team meet the goal of the Iteration (Sprint). This usually means picking up work on the highest priority story since this maximizes the value delivered and the reduces the risk of meeting the goal of the Iteration (Sprint). It also helps broaden the team members understanding of the work as while they may not be the expert in the area represented by the task, they will learn something as they do the work. In general it is good to have these more flexible team members as it creates a team which is better able to deal with any requirement thrown at them, increasing the overall value of the team.
  
-There are times when it does not make sense to pick a (sub-)task on the highest priority story, but again, she is the best person to figure this out as she has the context of all the other work going on and the overall goals of the Sprint. The Daily Scrum also offers a forum for other team members to participate in the discussion of what's next. This works provided no-one falls back on old behaviors and tries to assign work to another team member.+There are times when it does not make sense to pick work on the highest priority story, but again, she is the best person to figure this out as she has the context of all the other work going on and the overall goals of the Iteration (Sprint). The Daily Scrum also offers a forum for other team members to participate in the discussion of what's next. This works provided no-one falls back on old behaviors and tries to assign work to another team member.
  
 By working this way, we get a number of benefits: By working this way, we get a number of benefits:
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/how_is_work_assigned_during_a_sprint.1591818749.txt.gz · Last modified: 2020/06/10 12:52 by hans