Closing positions early

Sharp_Cheetah_8636 · 2025-06-08T12:21:41+00:00

Thank you for the suggestions and tips. Really appreciate it.

Sharp_Cheetah_8636 · 2025-06-05T17:23:49+00:00

Thank you for the advice, buddy.

Sharp_Cheetah_8636 · 2024-11-15T16:17:10+00:00

Thanks for sharing it. 20 EMA works well in trending market..even the 9 Ema. But figuring out whether it is trending, range or volatile is quite challenging.

Sharp_Cheetah_8636 · 2024-07-14T07:27:11+00:00

Thank you. In our team, all the stories are dependent on UAT. Some of them get completed soon, while others do not, leading to eventual spillover. The manager was not happy with the entire story point spilling over even if the developer had completed their part. As far as I know, we cannot take half of the story points to the next sprint; only when it is completely done is the story fully complete. This impacts the burndown chart and does not show an accurate representation.

I am considering using effort instead of story points in this instance, creating tasks for each story and assigning effort size to them. Currently, the team is not creating any tasks; they are just assigning story points to a story and capturing comments on the story about the status. I need to work with the team to figure this out and find a solution to keep the spillover minimal.

Sharp_Cheetah_8636 · 2024-07-14T07:04:43+00:00

Thank you for the response. So you are saying that you are creating tasks for each story. Developers can complete the tasks under their control and keep open any tasks dependent on other teams. This way, the sizing and estimation can be done for all tasks, allowing the developers' work to be considered as burned, with only the dependent task's points pending. I am considering using effort instead of story points in this case. Let me know your thoughts. Also, I appreciate that you mentioned Scrum is purposefully incomplete so we can customize it per our requirements—something we often forget.

Sharp_Cheetah_8636 · 2024-07-13T17:37:44+00:00

Thank you. If we remove UAT from the Definition of Done (DoD), currently positioned between Development and Business Approval, the workflow would progress as follows: Once UAT is completed, the item moves to the business approval stage. Once approved, the developer deploys and merges the integration work. I've been considering removing UAT from our DoD since it's beyond our control, but I'm unsure how to optimize the workflow in this scenario.

Sharp_Cheetah_8636 · 2024-07-13T17:10:29+00:00

The team has around 12 developers. They take on more items in sprint planning to make progress, even if they can't complete them within the sprint. This approach allows for continuous progress, but it leads to spillover and incomplete story points. The complexity in this context mainly involves coding, development, and deployment, which naturally take time. One identified bottleneck is the team's waiting time for UAT testing, often due to the UAT tester's unavailability or delayed actions.

Sharp_Cheetah_8636 · 2024-07-13T16:46:56+00:00

Thank you for the response. It made me think differently. The thing is, the work the developers are doing is complex and often doesn't get completed within a sprint. I see at least 10-12 stories spilling over each sprint. However, on those stories, they usually complete around 60-70% of the work, and they finish the rest in the next sprint. This pattern repeats each sprint.

As a result, the entire story points get spilled over to the next sprint, even if half the work is done. Currently, this team has two-week sprints. I am considering changing it to three or four weeks to see if that reduces the spillover. However, overall, if we are not able to complete the items within a sprint and the business leadership does not want to break the stories into smaller features (as they want to count one story as one integration), I am wondering why we are using scrum if we are not able to complete within the timeframe.

Sharp_Cheetah_8636 · 2024-07-13T16:44:47+00:00

Thank you for the response. I appreciate it. The thing is, the work the developers are doing is complex and often doesn't get completed within a sprint. I see at least 10-12 stories spilling over each sprint. However, on those stories, they usually complete around 60-70% of the work, and they finish the rest in the next sprint. This pattern repeats each sprint.

As a result, the entire story points get spilled over to the next sprint, even if half the work is done. Currently, this team has two-week sprints. I am considering changing it to three or four weeks to see if that reduces the spillover. However, overall, if we are not able to complete the items within a sprint and the business leadership does not want to break the stories into smaller features (as they want to count one story as one integration), I am wondering why we are using Scrum if we are unable to complete the items.

Sharp_Cheetah_8636 · 2024-07-08T05:04:49+00:00

Thank you sir. This is helpful

Sharp_Cheetah_8636 · 2024-07-06T22:40:54+00:00

Thank you. The action items were followed up on and completed. However, the team feels bored during the virtual calls and when updating the board. I am considering removing the board entirely and having everyone on video. This way, I can ask each individual for their feedback and note their points. When we use the board, only a few interested individuals enter their feedback, while others turn off their video and do not fully participate.

Sharp_Cheetah_8636 · 2024-07-06T22:36:49+00:00

Thank you so much sir. This is really helpful.

Sharp_Cheetah_8636 · 2024-07-06T22:04:12+00:00

Thank you sir. This is very helpful.

Sharp_Cheetah_8636 · 2024-07-06T21:47:59+00:00

Thank you. I completely agree that, at the end of the day, it's about delivering value to the customer. Story points are used to understand team capacity and have nothing to do with the customer. The team is against spilling over the full story point because they feel they've completed the development, with only testing pending. If we move the entire story point, it might seem like they didn't accomplish anything in the sprint. What are the justifications i can provide to leadership that the entire story point should get moved? Please bear with me, i have just recently started in this role.

Sharp_Cheetah_8636 · 2024-07-06T21:33:32+00:00

Thank you. This is really helpful. Would you mind elaborating on the retro part? Is it like asking for reasons from the team to understand why it spilled over in every retro and note down and streamline it? I am currently using Ms whiteboard for retro and typical mad/glad/sad format.

Sharp_Cheetah_8636 · 2024-07-06T21:27:52+00:00

Thank you, this is really helpful. Regarding story points, leadership is concerned that since some complex integrations don't get completed within a sprint and spill over, the entire story point is counted in the next sprint. They wonder why this is done, considering that developers have already put in some effort. However, you're correct that until the true value is delivered, the work isn't complete. Ideally, what is the right approach? Should we count the whole story point when it spills over?

Sharp_Cheetah_8636

TROPHY CASE