There is a lot going on here. The short answer is that the Sprint Review does not have to be a demo but Scrum does advocate that the team should produce a potentially shippable product increment. That means the code is able to be shipped even if the Product Owner chooses to hold it back for whatever reason.
Breaking Down Your Post
- Scrum is not an acronym. It is just Scrum; it comes from rugby. Imagine the ball is the goal of a project and as a team you are just moving it down the field a small iteration at a time
- Anything you want is optional, it just means that you are no longer doing Scrum, There is a difference between doing Scrum and being Agile. Agile is a set of values. Scrum is a framework that you can add things to but not take things away from
We have one week Sprint but due to application architecture complexity
There one sentence alone could form the basis of a retrospective. Why is the architecture complex? Are you working in a tightly regulated environment? Have the business mandated it that?
There are no wrong answers so just be really honest. Scrum Teams cannot always change their work environment.
What technologies are you working with? Do architectural decisions have to pass through a TDA or a CAB and does that impact the success of your sprints? Do you have a full time architect? Are you trying to work with an emergent architecture or plan everything up front?
Each of these items unlocks another little part of the puzzle to make Scrum a success. In highly dependent infrastructure projects where the requirements are known then Scrum (short sprints) is not always the optimal solution.
For instance, in business intelligence there is a large part of the data strategy that must be built up front and cannot be delivered incrementally/emergent because the rework penalty would be so high and the business would suffer.
However, most projects can be delivered incrementally if a business is willing to change it's behaviours. Be really honest; what is your project attempting to accomplish and how?
we unable to product working software in end of week.
Why not? Is this due to organisation barriers or the technology implementation? What is the shortest period of time that you do think you could produce working software? Are all parts of the project struggling with the week-long timebox or simply infrastructure?
In planning we are committing logic components development completion
Are you breaking down Epics and User Stories to a granular enough level and are you using the INVEST criteria to evaluate stories? Are you refining stories before Sprint Planning and do you have a BA to support the activities?
Also, remember that in Scrum, the planning ceremony is a forecast, not a commitment. The easy way to stop the business punishing slipped items is to gradually take less and less into the Sprint until you never miss a forecast.
in review we are providing update PO and Stakeholders on the status of Sprint backlog( how many we achieved and how many we slipped and what happen to make it or slip it)
Do you have a Scrum Master and are they supporting this activity? What is the PO doing during the Review?
Remember, the primary goal of the Review is to gain feedback on what has been delivered or is underway. It is a chance for stakeholders to see the vision of the product and inform the builders whether that is what they had envisioned. It is not to make teams feel bad for missing forecasts or focussing on what slipped.
It is not to evaluate the project for hitting an arbitrary timeline or metric of completed user stories. Especially since we could game that metric very easily but taking the large story and making it 50 one-line stories. Suddenly the team have hit 98% productivity and only 1 user stories remains saying deploy... (Don't do this. I am just showing how arbitrary Agile metrics can be manipulated).
Or can we agree a set of PBI and achieve those by keeping demo as optional (do if end to end development completed)?
From Scrum.org: Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. There could have been a single deployment or many deployments during a Sprint which lead up to that Increment to be inspected.
- The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”
- The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
- A collaborative discussion about timelines, budgets and other product/project administration if appropriate
Other Questions that an Agile Coach or a Scrum Master should ask
- Do you have a Definition of Done? If so, what does it say and is it valid and when was it last updated?
- Do you have play ready stories and have they been suitable broken down into small enough chunks to ensure sprint success?
- Do you have all of the skills within the team that you need?
Unfortunately this post has become less about giving you the answers and more a chance for you to start framing the problem in a way that a Scrum Master or an Agile Coach would you help you work through it.
As always; the first line support for your question can be found in the Scrum Guide and from your Scrum Master. Second line support should be your organisational Agile Coaches. You cannot go wrong simply reading the Scrum Guide and, if the advice is too difficult, asking why it is difficult within your organisation and project.