I have a user story for a login screen. It is in the active sprint. Part of it (andriod platform) cannot be done any time soon. The Sprint is almost over. What can I do?
Should I divide the user story? Like ui, integration and all other functions?
-
1Can you give more context? It's not really clear to me what the problem is? One of your stories is late, and this login screen one depends on it?– ErikCommented Jul 5, 2018 at 14:53
-
Is the Sprint Goal dependent on this story?– Todd A. Jacobs ♦Commented Jul 6, 2018 at 14:41
-
in my project, i create sub tasks from user story to both platforms " android and iOS" and as android will use new technology, late occurs,this will lead to move user story to next sprint, and this will occur for all user stories because user story contain sub tasks for both platforms– user32866Commented Jul 8, 2018 at 7:11
-
That is a bad user story and bad use of sub-tasks. A sub-task is something only an individual developer will be concerned with. A user story that requires both iOS and Android functionality built and tested is not a user story.– Venture2099Commented Jul 8, 2018 at 18:19
-
please, could you explain more with example, lets say we have login screen that contain email and password field also contain link for forget password, what user story and its sub tasks of this screen " note that i have 2 platforms android and ios" also task for create API will belong to what?– user32866Commented Jul 9, 2018 at 4:23
Add a comment
|
3 Answers
You could split that story, but probably not along the lines you are thinking of.
If you can split the user story in two independent stories, then great. Go ahead. Learn from it and do it from the start next time.
However, the parts you mentioned are not a user story. "UI is done but backend is not" is simply a story that is not done. Because "UI is done" is no user story. The user does not care what part is technically done, the user only cares for done. And if the UI does nothing when the user clicks the button, it's not done. A UI without functionality has no value to a user.
It sounds like your user story is simply not done. That's not a bad thing. Just note what is left to do, redo your planning method on the rest and plan it for a later sprint (or scrap the story if no longer needed). There is no special need to do anything with it.
You are facing several problems here which are bleeding over into each other. Let's separate them out.
Story is not done. What to do now?
Let's assume your user story was perfect and you have simply run out of timebox. What do we do with not-done user stories is a bit of a divisive debate in the Agile community, largely concerned with re-estimation. You can find flavours of that question here on PM StackExchange. For example; In scrum should incomplete stories be re-estimated or does the original estimate get burned down when it's finally completed?. You can also refer to this guide by Mike Cohn which represents one side of the Agile debate (not re-estimating).
Story not done. Root cause: it was not a suitable story.
This is harder to solve without granular detail of your project and technologies and organisational structure. We know what the technical guidance says ("User stories should be a complete slice of functionality") but sometimes in some teams that is simply not feasible. Salesforce did an excellent series of blog posts about where UX sits in the Scrum framework. Like most things in Agile, it is up for discussion and YMMV.
Note: This is where @Nvoigt and I would probably respectfully disagree. UX can be a user story. It depends on the delivery. I have been part of teams that consider wireframes, click paths and PoC's to be valid user stories representing team effort. It all depends on the context; are you making UX stories to avoid harder levels of integration or are you making UX stories to achieve arbitrary timeboxes or do your UX stories genuinely make sense etc etc..
How to tackle this right now?
My advice is, don't sweat it. It is one story. Simply mark it not done. It goes to the top of the backlog and you bring it into the next Sprint and it is picked up almost immediately by the devs. No trouble. 100% predictability is an aspiration but not a reason to crucify your team with debates.
How to handle this moving forward?
Dedicate a portion of your retro to this particular story. How did it end being mis-estimated? Was a developer absent and they were a bottleneck? What specifically happened to this story? Use that to drive further questions about your story authoring, splitting and refinement patterns.
-
Actually, this because Late in one platform" use new technology" will be for all User stories, i not know what to do for this as the sub tasks of both platforms linked to this user story Commented Jul 8, 2018 at 6:33
Do as much as you can on the story and if it is incomplete at the end of the sprint return it to the backlog for consideration in the next sprint.
Discuss what happened in your retrospective. Things to consider:
- Did you commit too much to the sprint?
- Was there a problem with this particular story?
- Is the team's velocity accurately predicting your capacity for a sprint?
- Any other lessons you may learn
Occasionally failing to complete a story is not a problem. It is an opportunity to learn.
answered Jul 6, 2018 at 14:09
