UI design spikes on the backlog?
- Hi everyone -
I am currently faced with having a bunch of User Interface designs spikes being added to my backlog during Sprint Planning, and their number keeps on growing each time.
These spikes were not planned for and estimated during Release Planning and are the results of not having the wireframes for the product ready in time for the development team to work on (and the designers not keeping up with the development team and have design tasks on the "real" stories instead of spikes)
This impacts my release burndown and contingency because these spikes keep adding scope and, besides that, they're basically single-sided stories that require _only_ design tasks, without _real_ user value.
I am thinking about creating a Design swim-lane and putting all the design spikes on that lane without actually counting them towards the release burndown. Just for tracking purposes.
I am also thinking about doing the same thing for any other type of single-sided stories that might come up in the future. e.g. a story or spike _only_ for Documentation, that involves only documentation related tasks.
Any thoughts on this approach or other suggestions would be highly appreciated by yours, trully,
- (responding to Roy)>
>Yes, I was referring to the P.O. making this judgement and conveying
> Who is telling who that this is so way down the priority list
> that it is unlikely to happen?
> If it is the PO telling an interested user, who the PO is
> actually representing, then there is no problem, ...
> > pauloldfield1 wrote:
> > Hmm... "After a very quick look at value and cost, this is
> > so way down the priority list that it's not likely to
> > happen. If you want something along these lines, can you
> > go away and think of ways to increase the value or decrease
> > the cost?"
> > That's honest and not disrespectful. It might work.
it to the stakeholder. I guess my pruning of context was a bit
too excessive on this occasion. Sorry. Normally it's a good