Menu
If a story is in progress and then swim lanes are code review and QA-ready, how should the assignment of stories work? Should a story remain assigned to the developer? And should the code review and QA tasks be created as sub-tasks in it? Or should the story be re-assigned when it is moved to code review by the developer, and when code review is done, it is moved to QA lane by the reviewer and re-assigned to QA by the reviewer. It seems anti-pattern to re-assign tickets from in-progress to future states. It looks okay to re-assign tickets before it was brought in the sprint but not after.
594
By the end of the Sprint the task estimates will effectively be actuals. However the story points themselves will not be amended.
A new story can be added to a sprint if you take a correspondingly sized story out (the new story needs to be estimated by the team, and the team must accept this change as feasible). A significantly changed sprint can be abandoned. You may stop the sprint, and start a new one from scratch, with a new planning meeting.
Also, it is easier to move the user stories position in Sprint, using drag n drop. At Sprint board, click on the “Backlog” option from the right navigation panel. Click on the “+” icon on next to User Story and it will be added to the currently loaded Sprint. User Story will be added at the top of the Sprint.
A change in the story or adding a story is a change in the Sprint plan. A change will be accepted within the same sprint only if: The change has been confirmed with the customer. The change aligns well with the value proposition of a story in the sprint.
The team should be aware of the current team velocity and use those metrics while estimating the stories during sprint planning sessions. Properly segregate user stories in the sprint backlog into easily developable tasks. The tasks should not be granular.
If the effort to apply the changes would put the rest of the sprint at the risk of failing, the better option would be to drop the changed story for this sprint and bring it up again with the changes during the next sprint planning.
If the story gets finished in sprint 11, the 5 points will contribute to the velocity of sprint 11. The ‘missing’ 3 points will not be added to veloctity of sprint 10. The velocity of each sprint is based only on the story points of the user stories that were completed in that sprint.
Write a new user story for the changes and prioritise it so that it gets into the next sprint. Drop the changed user story for this sprint, rewrite the user story and do it in the next sprint.
Scrum does not have anything to say about how the work is done nor how a board is managed. However, many team's look at Kanban's "pull" approaches to answer this. In that case, work is never assigned or given, it is only claimed/taken on. Therefor, work would be moved to "Code Review" by the reviewer when they began the work. Similarly, the work would be moved to QA by the tester when they started. "Ready" columns are a bit of a misnomer as they are not states. Rather, they are statuses of the previous state. If your order is Code Review - QA Ready - QA, then in fact, QA ready is a possible designation on work in Code Review. This may seem minor, but it is very important to prevent pile-ups in your process where work stalls without owners.
144
There is no single answer, but one way of doing it is to think of of a User Story as a container of tasks where each task is a small technical deliverable of any kind. With this mindset you can effectivly stop thinking of who the assignee is as each developer will have its small contribution towards the goal.
One of the problems with task re-assignment is that at one point you can loose traceability of who has done what and productivity on per developer basis. So in this sense having each teammember doing its own tasks and delivering towards the completion of a user story can solve this.
Then you can assign the User Story to the product owner, or you can assign it to a developer that kind of holds ownership towards its delivery to test when the tester will take over. But the user story when assigned to a developer does not mean that he owns the User Story, it just means that it is his responsibility to ensure hand over to test nothing more nothing less.
When a tester encounters a bug then you create a bug attached to the User story.
24
Not recommended. It's feasible tho. You have to assess your current work situation. If the user story is something that can make a whole difference, then it would be better to just stop the sprint, reassess your situation and make the necessary changes - then continue. Either way, when you are adding a new user story to the backlog, deadlines can be hardly met.
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
