Skip to main content

Howto handle 'lost freedom' of dev members

Last post 02:36 pm February 9, 2016 by Andrzej Zińczuk
8 replies
08:24 am February 9, 2015

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?


09:30 pm February 9, 2015

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.


11:34 pm February 9, 2015

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/


01:48 am February 10, 2015

"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)?


05:00 am February 10, 2015

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.


07:35 am February 10, 2015

very succint answer, Ian.


03:39 am February 11, 2015

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?


06:23 pm February 11, 2015

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.


02:36 pm February 9, 2016

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


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.