Skip to main content
deleted 29 characters in body
Source Link
Sarov
  • 14.8k
  • 5
  • 34
  • 64

In a sprint (#1) we decided on tasks and user stories. One of the task we thought of 6 hours turns out to be a difficult one, due to technical complexity. The complexity was such that we can't estimate it even in the middle of the sprint. All we knew that we can try to fix it with plan A, if not then plan B, if not then plan C. After each plan execution we retrospect and deviced plan D,E,F. Eventually the commited user story spilled to next sprint (#2).

Now under same user story, in sprint #2, in another task developer notice due to frequent requirement changes the code is NOT in good state. Thus it should be optimized as well. So developer done the optimization under same tasks, which took time obviously and user story spilled to sprint #3.

In sprint #3, there were bugs for the same user story which were fixed timely and sprint #3 went fine.

I do not see any performance problem OR job not done correctly by the developers. But our 2 out of 3 sprints shows 1 user story spilled twice and thus those sprints are red.

Now my questions: Q. What went wrong in managing our sprints? Q. What measures we should have taken to make our first two sprints green? Q. How to handle the alert raised by the developer about the code quality?

One last generic question, making sprint GREEN, is the whole and sole goal of the team?

Please help!

Thanks.

In a sprint (#1) we decided on tasks and user stories. One of the task we thought of 6 hours turns out to be a difficult one, due to technical complexity. The complexity was such that we can't estimate it even in the middle of the sprint. All we knew that we can try to fix it with plan A, if not then plan B, if not then plan C. After each plan execution we retrospect and deviced plan D,E,F. Eventually the commited user story spilled to next sprint (#2).

Now under same user story, in sprint #2, in another task developer notice due to frequent requirement changes the code is NOT in good state. Thus it should be optimized as well. So developer done the optimization under same tasks, which took time obviously and user story spilled to sprint #3.

In sprint #3, there were bugs for the same user story which were fixed timely and sprint #3 went fine.

I do not see any performance problem OR job not done correctly by the developers. But our 2 out of 3 sprints shows 1 user story spilled twice and thus those sprints are red.

Now my questions: Q. What went wrong in managing our sprints? Q. What measures we should have taken to make our first two sprints green? Q. How to handle the alert raised by the developer about the code quality?

One last generic question, making sprint GREEN, is the whole and sole goal of the team?

Please help!

Thanks.

In a sprint (#1) we decided on tasks and user stories. One of the task we thought of 6 hours turns out to be a difficult one, due to technical complexity. The complexity was such that we can't estimate it even in the middle of the sprint. All we knew that we can try to fix it with plan A, if not then plan B, if not then plan C. After each plan execution we retrospect and deviced plan D,E,F. Eventually the commited user story spilled to next sprint (#2).

Now under same user story, in sprint #2, in another task developer notice due to frequent requirement changes the code is NOT in good state. Thus it should be optimized as well. So developer done the optimization under same tasks, which took time obviously and user story spilled to sprint #3.

In sprint #3, there were bugs for the same user story which were fixed timely and sprint #3 went fine.

I do not see any performance problem OR job not done correctly by the developers. But our 2 out of 3 sprints shows 1 user story spilled twice and thus those sprints are red.

Now my questions: Q. What went wrong in managing our sprints? Q. What measures we should have taken to make our first two sprints green? Q. How to handle the alert raised by the developer about the code quality?

One last generic question, making sprint GREEN, is the whole and sole goal of the team?

Source Link

Making sprint GREEN

In a sprint (#1) we decided on tasks and user stories. One of the task we thought of 6 hours turns out to be a difficult one, due to technical complexity. The complexity was such that we can't estimate it even in the middle of the sprint. All we knew that we can try to fix it with plan A, if not then plan B, if not then plan C. After each plan execution we retrospect and deviced plan D,E,F. Eventually the commited user story spilled to next sprint (#2).

Now under same user story, in sprint #2, in another task developer notice due to frequent requirement changes the code is NOT in good state. Thus it should be optimized as well. So developer done the optimization under same tasks, which took time obviously and user story spilled to sprint #3.

In sprint #3, there were bugs for the same user story which were fixed timely and sprint #3 went fine.

I do not see any performance problem OR job not done correctly by the developers. But our 2 out of 3 sprints shows 1 user story spilled twice and thus those sprints are red.

Now my questions: Q. What went wrong in managing our sprints? Q. What measures we should have taken to make our first two sprints green? Q. How to handle the alert raised by the developer about the code quality?

One last generic question, making sprint GREEN, is the whole and sole goal of the team?

Please help!

Thanks.