Design vs. Sprint Sizing/Tasking

I'm on a scrum team, and enjoy the bottom up approach. I like that the development team has the opportunity to give legitimate estimates which actually drive the amount of work that gets accomplished during a two week sprint.

That being said, it's very difficult to reconcile design tasks with user stories. I'm the first to admit I'm not a proper designer. Nor am I the ScrumMaster on the team -- however I'm the Dev. Lead on the team. It's somewhat equivalent to being the square peg in the round hole -- not quite relevant to Scrum; not quite product manager for Waterfall. However, I've been the primary fighter for team rights as far as meeting the scrum process goes. The big deal now is reconciling the Cooper methodology of user stories and true goal-based design with the pure Scrum methodology. Where do design tasks go? How do you have a fully "designed" site with consistency not just of appearance, but more importantly behavior?

That's a big deal (TM), and not a problem that can be solved overnight. Our approach thus far has been to remove the design tasks from the Capacity planning within a sprint, but I don't believe this is ideal as it has essentially removed the designer from accountability within the sprint. Hopefully I'll be able to provide more insight into this, as the team figures out how best to deal with the situation, and what feels most natural. What is definite is that designers can not just work 'off the books'.

Posted on 10/3/2008 9:26:00 PM by Jason Nadal

Permalink | Comments |

Categories: scrum

Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
blog comments powered by Disqus