Practicing Scrum and Agile, our team had Sprint Planning and we sliced our features into stories. However our team was unsure about what should the "third" story do, so the ScrumMaster decided that we could enter a placeholder for that story on our board until further information is relayed back to the team from the PO. A placeholder is a generic story stating TBD. Is using a placeholder for a story keeping within alignment with Agile and Scrum process?
1
-
Welcome to PM.SE! Seems that you guys are falling into the 100% utilization fallacy. That's a dangerous path.– Tiago CardosoCommented Oct 3, 2020 at 9:33
Add a comment
|
3 Answers
Your Product Owner should be available during planning to answer any questions that appear concerning the stories. If question could not be resolved, because the Product Owner was not there or could not sufficiently answer the question, then the story is not ready and should not be in the sprint.
A placeholder is not a good idea. Sprint planning is making a plan for the next two weeks. If you don't know the details, then you cannot make a plan. You cannot plan with a blank card.
The biggest problem here is the "relayed back to the team from the PO" part. The PO is part of the team and is a part of planning. The PO does not have a proxy that information is relayed through, it is a single approachable person that you can talk to and discuss your questions with directly. If that is not the case, something is wrong in your Scrum implementation.
-
I thought a placeholder is "no harm," but now I see the damage to the process. Commented Sep 30, 2020 at 18:54
-
Hmmm...whilst I don't disagree with any of that in principle, the OP is not providing enough context. If the story is something as simple as "Change the copy of the website; just getting the copy approved" it is much more permissible than "Choose a type of database and build it..no further details known". We need a bit of nuance. I would also add that there is no Definition of Ready, it is a misnomer. If the team are happy to take Product Backlog Items in an unclear state then that is perfectly fine. The team are the best judge of what is pragmatic and achievable. Commented Oct 1, 2020 at 14:00
-
Just to add; I do agree. 99% of stuff that is not ready, does not go in the Sprint. But, it sounds like in this case, the third story was dependent on the result of the first two stories. So, if the team leave a gap in their commitment and offer to fill it in with a third story if there is time; that is fine. Best not to commit to it early though. Rather leave it out and keep it on top of the backlog for inclusion if they have capacity, Commented Oct 1, 2020 at 14:02
nvoigt stated the problem very well. I would just add that each sprint is supposed to work on the highest priority items on the backlog at that time, so the fact that one of these things is somewhat unknown suggests there hasn't been enough focus on what is most important.
Many Scrum teams will frequently "refine" the backlog by adding new stories, details and estimates with the aim of making sure the priority stories are ready to work on by the time they go into Sprint planning. This activity of backlog refinement is the responsibility of the whole team, PO included. The Scrum Guide suggests that teams should spend up to 10% of the time in each sprint on backlog refinement.
IMHO, short answer for this: Yes, there is no harm to have placeholders for future stories (& it's a good tool to not forget works in future sprints)
Longer answer, the placeholders should be refined before Sprint planning as Nvogel mentioned. If it's not the case, & PO is not there or cannot answer immediately in the planning meeting (which I saw several times), Development team can decide whether they can commit the item into the Sprint or not. The uncertainty factor can be counted to increase size of the item (which subsequently takes more room for other items).