Howto handle 'lost freedom' of dev members
We did introduce scrum 3 month ago.
It worked mostly well, but there is still two issues which itches us.
1. Some complain that they loose freedom in choice of work when they have to split a feature into tasks. They argue that sometimes it just doesn't make sense to create tasks for some features, especially if it is an explorative feature.
A sample for such an explorative feature would be an analyse whether we should use less/sass/plain css/ or buy a style for our own crm framework. This is a task which takes some time, but it is hard to foretell what must be done and in which order.
Q: How should such tasks be handled in a sprint? Just create one feature and let a dev work on it for a given amount of time?
2. Similar as the first question: Some find creating tasks feels artificially, and there is no benefit for some tasks.
E.g. there is a feature where it clear what has to be done, and it will require about 3pd. Should we still create tasks for it, or can we just use the feature within a sprint?
Hi Manuel,
Who said that you have to split feature into tasks? It depends on the type of work. Scrum does not recognize feature or task, only Product Backlog Item.
Why can't explorative technical work be decomposeable and estimateable (albeit estimated differently than a purely functional PBI)? The work is a technical spike, right?
http://johnharo.net/agile-should-you-estimate-spikes-with-story-p
http://www.c2.com/cgi/wiki?ArchitecturalSpike
http://www.scaledagileframework.com/spikes/
"2. Similar as the first question: Some find creating tasks feels artificially, and there is no benefit for some tasks.
E.g. there is a feature where it clear what has to be done, and it will require about 3pd. Should we still create tasks for it, or can we just use the feature within a sprint? "
Does getting this PBI "done" involve all the work related to analysis, design, coding, testing (functional & non-functional), documentation (if required by PO), etc in accordance to the Definition of Done & delivering a potentially releaseable product Increment?
How is the PBI discussed during the Daily Scrum -- How does the Development team inspect (and adapt) its progress for this PBI(s)?
Each item on a well-formed Product Backlog will have a size. Only the Development Team can estimate that size, which implies that they must understand the item well enough to be able to size the work that will be involved. This may eventually translate into the identification of individual tasks during Sprint Planning.
If the Development Team are uncertain of a PBI's size, and therefore of whether or not they will be able to complete it to the satisfaction of the Definition of Done by the end of the Sprint, then they should not induct it into their Sprint Backlog. Instead, it should be clarified further during Product Backlog refinement sessions. Spike investigations can assist in the process of refinement.
very succint answer, Ian.
I appreciate all the answers.
@Joshua: This might not be core part of scrum, but it was teached like this when i did scrum master and product owner course
And there are lots of resources which describe it that way.
*http://www.scrum-breakfast.com/2011/02/how-we-do-sprint-planning-2.html
*http://dl.dasscrumteam.com/DST_Scrum_Overview_EN.pdf
@John Pluto: Thanks for this input. I guess this(technical spike) is what we were missing for such explorative PBI.
About the second question: Getting this PBI done involves all you've mentioned, and at the end it is in accordance to the DoD.
At the moment, we create tasks which are equal or smaller than a day, but it just feels awkward
Sample: We create a wizard control which then can be used by a proper API
TASK 1: Setup Project, init UI design, API design
TASK 2: Implement Navigation
TASK 3: Make it Responsive
In this sample, we create a task for making the control responsive, but this must be considered at the beginning of this PBI implementation.
Question:
*Should we still create such tasks?
*Should we create a single task "Wizard control" which then would take 3-4 days of work?
*Any other hints to make the tasks not feel that alien?
I've seen backlogs as 1, 2, 3 and I've seen backlogs with less detail. The level of granularity of the decomposed work for the PBI (in this case Wizard control) is an internal Dev team decision -- as long as the team can inspect (and adapt/correct) its progress on a daily basis. The true progress of a PBI in the Sprint Backlog must be transparent to the entire team.
https://www.scrum.org/About/All-Articles/articleType/ArticleView/articl…
Sprint Guide July 2013
Sprint Backlog
The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal.
One of the reasons which may bring such acting is way how to response the change made by scrum implementation. Some of old behaviours are going to be changed and not everyone can like it. If someone had free hand to do work (including task slicing) it may be some challenge for him to apply whole team approach