Should UI/UX tasks we sized or not?
Hi everyone.
Some time ago I posted a similar question on Spikes, and I concluded from your answers that Spikes should not be sized but assigned a time-box and be considered inside the percentage of the capacity reserved for refinement, normally 10%. So in other words, while a user story would be sized in user story points.. a Spike should have a time unit based on the refinement capacity assigned to the team
https://www.scrum.org/forum/scrum-forum/36679/dealing-uncertainity-when-sizing-stories-spikes-or-bigger-user-story-size
But now it is the turn of UI tasks. We are refining a user story, so then the UI mock up has to be done by a deleveloper so we can add more acceptance criteria and size properly. Doing the UI mockup would be part of the Definition of Ready of the user story.
A programmer wanted to size the UI mock up task, stating that even though it is not an increment of working software it is an increment since a piece of work was completed. I answered that following the same logic as the Spikes that this should not be sized.
My logic is:
It goes agains the agile principles stating that the working software in the main measurement of progress. Also in the Scrum Guide it says that an increment is a piece of done functionality that is usable, testable and potentually shippable. Clearly a UI or UX mock up of a user story is not this.
Additionally, since the UI/UX mock up task, is part of the definiiton of Ready, I believe that is a "refinement activity" for a user story. Therefore it should not be sized. The user story later should be sized, having the mock up, acceptance criteria and other element of our definition of Ready.
So the increace of these UI tasks in the Sprint would turn into a descrease of velocity in the team since the programmers will have less time to code real product and more to refine, doing mockups .
Anyway, I also understand that sizing these tasks could make it easier to a more correct sprint planning, if the UI task takes too long and not sized it is very dificult to plan before-hand how many user story points to committ based on historical velocity based on user stories only. This is mainly since I do not think you can give a time-box to it as in the Spike?
Any thoughts about this? For me this should not be sized, based in agile theory and be considered refinement so far but I would love to hear some other opinions? Am I in the correct path of thinking or this is wrong and these should be sized for some good reason I am not thinking? As I mentioned, I think that maybe not sizing and the planning for the sprint could be a problem...
Thanks in advance!!!
So in other words, while a user story would be sized in user story points.. a Spike should have a time unit based on the refinement capacity assigned to the team
That sounds like a reasonable approach, even though there's nothing to stop team members from estimating capacity using any method they want. From what you say, certain members are trying to conflate any and all work undertaken in a Sprint with the work planned for release. Maintaining a distinction in regards to how each is accounted for is therefore probably a wise move.
If UX is only a refinement effort, then it could be very similar to what many people call spikes.
Do you think this approach would also work if the team is validating hypotheses about the user experience throughout the sprint? What if an assumption about UX is made in order to release an item of perceived value, but then that assumption needs to be verified?
Could UX work ever be considered part of the workflow of a single Sprint Backlog item, perhaps before, during and after all other development?
Could UX be incorporated into the definition of "Done" in such a way that there is a clear deliverable, and that a timebox on the item is not enough to allow effective planning?
Does UX or UI work need to be performed to satisfy a definition of "Ready", or can a team use the Sprint in order to address those unknowns?
Thanks for you answers so far.
Simon,
At this point it is part of our definition of ready of the user story, so a programmer will create mock ups based on the initial draft of user story, this will help the PO or business analyst do some backs and forwards with them to do some modifications and then this will help a lot to decrease the level of uncertainty and ambiguity on acceptance criteria when writing it. So the user story will be ready to develop.
So I would asume that the UI\UX task will be done in one sprint and then will help to make its corresponding user story ready for development for next sprint. So as far as I understand this is a form of refinement task linked to the user story. The task is created to give visibility in the Scrum board for daily stand ups but not sized with user story points since when completed will not represent a done increment of the product. This is not a piece of testable, usable and potentially shippable product. So would this approach be the correct one?
if I follow the agile principles and scrum guide definition of increment, it should be ok. Like a spike task?
Anyway, in the case of UI\UX tasks, the programmer will not use a time-box event, I guess will use the time that is needed to finish it, therefore if not sized, since it is the amount of time is uncertain at least at the planning moment, how to plan based on velocity?. So how many user story points should I plan for the sprint if I have many of these unsized UX task mixed with sized user stories on a certain sprint? What about the motivation of the developer on doing something with no points?
In other words, sizing only user stories with user story points will give me a clean velocity which will represent only increments based on the definition of the scrum guide, but on the other hand, if I size also UX tasks, it would be easier for the planning phase? And motivation better?
Another issue that I would have with “sizing” UX tasks is that the variables taken into account for sizing would not be the same as for a user story, therefore a 2 points of user story would not be the same as 2 points of UX, therefore the mixed 4 points of velocity would be like mixing apples with oranges.
Size or not size UX tasks, that is the question (like to be or not to be) :-D
Any thoughts.?