Not all stories are DONE before sprint Demo..Now what ??
As per the Scrum guide, development team demonstrates "DONE" work.
So, what if - :
a. No story is in DONE stage till demo ? (Which in our case happens 3 days before sprint end)
b. Not all stories are in DONE stage. So , what about demo of stories that will be in DONE stage on the last minute of sprint end ?
c. Can we demo the work as and when developer completes the work instead of waiting for sprint review ? (Only BA, developer worked on the story, PO, SM ) will be present during this meeting. We anyways work in silos.
What is the difference between your "demonstration" event and the Sprint Review, and does it make sense to separate these two events, especially by a timeframe of days?
Why do you not consider your work done until the demonstration? If the desire is to demonstrate done work, then you should have the ability to come to a reasonable conclusion about the done-ness and likely acceptance of the work at a review or demonstration period.
Why does your demonstration happen so far before the end of the Sprint? Typically, the very last events in the Sprint are the Sprint Review (which is not exclusively a demonstration, but may include one) and the Sprint Retrospective.
Do you believe that the fact that you work in silos has an impact on getting work to a done state? What are you actively doing, on a team and organizational level, to break down silos and build cross-functional teams?
What is the difference between your "demonstration" event and the Sprint Review, and does it make sense to separate these two events, especially by a timeframe of days?
Why do you not consider your work done until the demonstration? If the desire is to demonstrate done work, then you should have the ability to come to a reasonable conclusion about the done-ness and likely acceptance of the work at a review or demonstration period.
Why does your demonstration happen so far before the end of the Sprint? Typically, the very last events in the Sprint are the Sprint Review (which is not exclusively a demonstration, but may include one) and the Sprint Retrospective.
Do you believe that the fact that you work in silos has an impact on getting work to a done state? What are you actively doing, on a team and organizational level, to break down silos and build cross-functional teams?
Hi Thomas,
By demo I mean simply demo and not review. On "Exceptional" basis can we show demo of some of our functionalities for early feedback is what I meant. There are no different opinion about Demo should be a part of sprint review.
About "Done" work- I mean what if our stories are not meeting "ALL" DONE criterias. Based on your reply I can assume- Even if story is not meeting "ALL" DONE checklist points , it's okay to show the demo provided we have reasonably completed work to show in demo.
Our demonstration happens 3 days before sprint end because developers get some time to work on the feedback before sprint ends.
We work in Silos- because there is no other way. Our work gets delivered without any issue so far. We have multiple irrelevant work items . But as a scrum master I have shared my opinion & explained the importance about working collaboratively and instead of taking different stories, think about share a story between two developers. After this discussion 2 developers got ready to work on single story .
By demo I mean simply demo and not review. On "Exceptional" basis can we show demo of some of our functionalities for early feedback is what I meant. There are no different opinion about Demo should be a part of sprint review.
About "Done" work- I mean what if our stories are not meeting "ALL" DONE criterias. Based on your reply I can assume- Even if story is not meeting "ALL" DONE checklist points , it's okay to show the demo provided we have reasonably completed work to show in demo
Our demonstration happens 3 days before sprint end because developers get some time to work on the feedback before sprint ends
I've had teams be successful in doing internal demos sooner, primarily to internal subject matter experts, members of the product management team (which may or may not include others beyond the team's Product Owner), and the user experience team. This can be a valuable activity. I would suggest that it's OK for work that is not totally done to be demonstrated to ensure that the team is on the right track. However, I'm in favor of activities being done just-in-time. So rather than waiting, demonstrations should include the right people at the right time, as quickly as possible to ensure that the team can incorporate feedback.
The end goal should be to ensure that the work meets the team's Definition of Done at the conclusion of the Sprint, going into the Sprint Review and Sprint Retrospective events.
We work in Silos- because there is no other way. Our work gets delivered without any issue so far. We have multiple irrelevant work items . But as a scrum master I have shared my opinion & explained the importance about working collaboratively and instead of taking different stories, think about share a story between two developers. After this discussion 2 developers got ready to work on single story .
I don't believe that "there's no other way". Maybe the team and/or organization is unwilling to change to support other ways, but it's not necessary to work in silos and it's a hinderance to success to work in silos.
Can we demo the work as and when developer completes the work instead of waiting for sprint review ?
Suppose you didn't do this. How else would the team set about eliciting feedback during the Sprint, and would it be as effective?
We work in Silos- because there is no other way.
How can you be sure there is no other way, and that the situation must therefore be accepted?
Our work gets delivered without any issue so far. We have multiple irrelevant work items .
Can you explain what you mean by work items being irrelevant, and why this doesn't cause issue? If the Product Owner does not consider them to be relevant, why are they on the backlog? Doesn't this negatively impact value delivery?
But as a scrum master I have shared my opinion & explained the importance about working collaboratively and instead of taking different stories, think about share a story between two developers. After this discussion 2 developers got ready to work on single story .
It sounds as though a way to avoid silos can indeed be found, if team members are willing to apply themselves to the challenge.
To your original question I direct you to the Scrum Guide's opening paragraph for the Sprint Review section (as always, emphasis added by me).
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
So what leads you to believe that only "Done" stories should be included in that event? Yes, there is a bullet point that says the Development Team demonstrates the work that it has "Done" but doesn't say that they only demonstrate the work that it has "Done". If the purpose of the Review is to gain feedback and discuss how the work that was undertaken impacts the direction of work, why wouldn't you review all work? ...elicit feedback and foster collaboration... You could do some of the same thing by doing interim demonstrations but I don't believe that they should replace the Review. As you said your team adjusts based on interim feedback so if you don't do the Review, how do you know your adjustments were made in a manner that is acceptable to the stakeholders?
As to the silo subject, I know you have another thread going here (https://www.scrum.org/forum/scrum-forum/30897/dilemma-story-points-or-capacity-what-should-be-considered-while-work) where that is being discussed at length so I'm not going to weigh in on that here other than to say that there are always alternatives and until you try all of them you will not be able to say that they are not valid. But I have yet to see any organization that was able to try other options without finding some alternative.
How can you be sure there is no other way, and that the situation must therefore be accepted?
After brainstorming with different team mates I came to conclusion. Because there is lack of willingness for becoming cross-functional team in terms of spread of knowledge or skills. Everyone is happy in their own shoes. For example AEM(Adobe Experience Manager) developer is not willing to take UI stories. Though, from this sprint we have assigned the one to AEM developer keeping in mind cross skill learning perspective.
Can you explain what you mean by work items being irrelevant, and why this doesn't cause issue?
For example, for this sprint we have below work items-:
1. Branch locator authoring in AEM
2. BrightCove- Multiple Video simultaneously playing issue
3. HTML 5 square infographic integration
4.Content Refactoring in UAT environment
5. HTML infographic user interface
Now, if we assign individual developers for each work item, we can complete all the work in one sprint. But, if we take lesser work (say on 3 work items) and assign multiple developers for single work items I find below issues-:
A. Some of the developers are happy to work in silos and not much willing to work in pair programming
B. Someone will still need to work alone. For example-:
User story 1- 2 developers
User story 2- 2 developers
User story 3- 1 developer <<<--- This guy is still working alone.
Having said this I would like to know what would you have done in this situation in terms of division of work?
So what leads you to believe that only "Done" stories should be included in that event? Yes, there is a bullet point that says the Development Team demonstrates the work that it has "Done" but doesn't say that they only demonstrate the work that it has "Done". If the purpose of the Review is to gain feedback and discuss how the work that was undertaken impacts the direction of work, why wouldn't you review all work? ...elicit feedback and foster collaboration...
Since it was specifically mentioned --"Development Team demonstrates the work that it has "Done" , I was not sure if incomplete work should be demoed or not. But your post clarified my doubt. Thank you.
As you said your team adjusts based on interim feedback so if you don't do the Review, how do you know your adjustments were made in a manner that is acceptable to the stakeholders?
No. I did not intend to skip review ceremony. I was just asking can we do demo before review as well for "Some" of the functionalities.
I would like to know what would you have done in this situation in terms of division of work?
If I was a Scrum Master in that situation, I would be very careful not to divide the work at all. Rather, I would coach the team that it is their responsibility to self-organize around the work as efficiently as possible.
- In Scrum, they must be able to deliver sufficient value to stakeholders that is of Done, usable quality.
- If there are any gaps in the skills the team needs, including those evidenced by silos, then I would work with them and the wider organization to resolve that impediment.
- I would make it clear to the team, the Product Owner, management, and possibly certain stakeholders, that only if there is a demand for change can matters be expected to improve. As far as possible, I would identify the risks to the team and the business of not changing, and make those risks transparent.
If I was a Scrum Master in that situation, I would be very careful not to divide the work at all.
By this you mean all 4 developers working on same story and accepting new story once the work on previous story gets over ? Would really like to know what do you mean by this ?
A. Some of the developers are happy to work in silos and not much willing to work in pair programming
B. Someone will still need to work alone. For example-:
User story 1- 2 developers
User story 2- 2 developers
User story 3- 1 developer <<<--- This guy is still working alone.
>>> What do you think about the PBI refinement and estimation ? Does the team together discuss each PBIs & estimate ? Does your DOD includes only development ? How does the team craft the Sprint Goal ?
I am just curious to know how the team collaborates on above.
Do you think reserving some time each sprint for cross training within team might help ? I always encourage my team to be T shaped than I shaped which benefits a lot in long run.
What do you think about the PBI refinement and estimation ? Does the team together discuss each PBIs & estimate ? Does your DOD includes only development ? How does the team craft the Sprint Goal ?
I am just curious to know how the team collaborates on above.
Team estimates PBI together.
Our DOD does not include Only development. Below is our DOD.
1Code review is completed
2Unit testing of user story is completed by the developer & passed
3Screensots of passed unit tests are taken by the developer
4story is Oked by UX team (if required)
5story is reviewed/demoed by/to the stakeholder and agreed concerns are taken care of
6Tester has tested the story and all functional tests are green
7Technical/authoring Documentation is updated (if any)
8Integrated into clean build
9code is refactored
Sprint goal is crafted by Business analyst and myself. Team does not craft sprint goal as we do have many unrelated items in sprint. So we create sprint goal out of the most important item(s).
Do you think reserving some time each sprint for cross training within team might help ?
Indeed it's good suggestion. Will work on it.
If I was a Scrum Master in that situation, I would be very careful not to divide the work at all.
Hi Iam , By this you mean all 4 developers working on same story and accepting new story once the work on previous story gets over ? Would really like to know what do you mean by this ?
Team estimates PBI together.
>> I think if this is the case then team is aware of topics/tasks in PB, and is able to estimate. Since PBIs are estimated together then tasks focused on different topics can be rotated within team each sprint. This might help in cross training and new learnings. Also how do you think Daily Scrum is being used by team ?
Code review is completed
>> if the code of 1 developer is reviewed by 2nd or 3rd developer , you are already collaborating on this single task.
Sprint goal is crafted by Business analyst and myself. Team does not craft sprint goal as we do have many unrelated items in sprint. So we create sprint goal out of the most important item(s).
>> Do you think when the whole team together will craft the goal they will be more focused and united towards achieving the goal ?
Hi Iam , By this you mean all 4 developers working on same story and accepting new story once the work on previous story gets over ? Would really like to know what do you mean by this ?
I'm not going to speak for @Ian but my interpretation of his statement has to include the second part of his statement. Here is his statement and I emphasized, in italics, the part you might have missed.
If I was a Scrum Master in that situation, I would be very careful not to divide the work at all. Rather, I would coach the team that it is their responsibility to self-organize around the work as efficiently as possible.
I see his statement less about telling/directing them in any way and instead educating them on why it is important for them to decide how to handle the work. He states that a Scrum Master should not dividing work which to mean implies not directing them at all. He states the a Scrum Master should instead coach the Development Team that they should consider multiple options and decide on their own how best to organize the work.
As @Harshel points out, there a many items in the Definition of Done that require collaboration and implies that there are silos of work but cross functional participation as well.
I see his statement less about telling/directing them in any way and instead educating them on why it is important for them to decide how to handle the work. He states that a Scrum Master should not dividing work which to mean implies not directing them at all. He states the a Scrum Master should instead coach the Development Team that they should consider multiple options and decide on their own how best to organize the work.
Thanks Daniel but I have coached about self organization , collaboration and the advantages , Scrum's expectations etc. But when you have multiple unrelated items in the sprint, team found it is best to assign unrelated story to each individual because apart from this they don't find any other alternative. In case you have faced similar situation please let me know how did you handle it and what you would have done in below situation. Please write in terms of below example only and not generally or theory wise.
Example:
1. Branch locator authoring in AEM
2. BrightCove- Multiple Video simultaneously playing issue
3. HTML 5 square infographic integration
4.Content Refactoring in UAT environment
5. HTML infographic user interface
@Daniel,
Can you please reply to my above post by taking the example given above.
Vishal,
Unfortunately, it seems you have individuals that prefer to work in silos, which actually inhibits self-management and cross-functionality within the team. In fact, I would go so far as to not call it a Development Team, but simply a working group loosely-connected perhaps by nothing more than an organizational reporting structure.
I think one key area you could try to coach these individuals on is to focus specifically on the work, and not on individual optimization or "assignment".
Basically, treat them as a collective, and not as separate individuals. Stress to them that, regardless of who works on what, they all share an equal responsibility to complete the items they forecast in a sprint. Ask them what their plan is to keep items moving forward in the event that someone working in a silo becomes unavailable for some reason (i.e. - illness, personal emergency, etc.).
Allowing an item to sit idle while someone is "out" is never an option, unless your intention is to promote an extremely-fragile organizational dynamic where progress can be halted by a single point of failure.