Sprint Log Management & commitments

There seems to be a lot of concern about schedules, and alleged commitments being made by a large group of people, but not much about releasing value into production.

How often is this actually happening, and how is the evidence from each release being used to adapt the Product Backlog and to improve any forecasts which might be made?

Peter,

What was the Development Team's response when presented with evidence that they are apparently over-estimating their capacity, and repeatedly falling short of their sprint forecasts?   

Did the team have any ideas or suggestions for improving their ability to estimate items and/or meet their forecasts?

Budget for product is set for a period of 80 wks.

c) I have reached my 28%  schedule and budget and only 4% of Product has been developed.  

How do you know what 100% of the product actually are and how was it determined that the product could be successfully developed in 80wks? To me it sounds a bit like scope, schedule and budget (capacity) have all been defined upfront starting development, which would be an indication of waterfall.

@Ian : This is is happening from the onset //after 8 Wks..  like i said 4 sprints were given for the team to mold together.  the rest of sprints 4 sprints .. always over estimated.. that is like 

@Tim,  the response from Dev Team, is that the underestimated complexity and Product owner/ User story has not clearly defined the expected result

@Steven, CAPEX was raised to deliver product X, with lets say 80 functional points.   This is MVP status.  Without these 80 points that come up as upfront  requirement, ( no this is not waterfall.. just porting old tech to new tech)There can be no further allocations of funds to move to the next phase.   Note: the 70 points already exist in an old system and another 10 were just added  as a new value add. 

Note: we are just on the onset of major transformation of technically and services..  old=>new  (old = old tech and methods ; new = new  infrastructure and tech idea) . e.g IoT /AI / RPA etcs to move the "old stuff" to "new stuff". The  10 new points fall into the new arena , but they depend on core methods of the base 70 points.

over all goal => Long term project with over 1K functional points that need to be implemented with at least 400 points moving into the realm of AI/BOTs/ RPA

I think this is an interesting space and ecosystem to work into..  

accurate estimates are committed too .

If it was accurate, would it be an estimate?

Is it feasible to ask someone to commit to something that is, by definition, uncertain?

a) How do we  acknowledge that the Devteam has the required skills and  understanding of delivering ?

What do they think about their DOD ? Are each increments "potentially shippable" ?

Thanks for clarification of the actual project setup. Still I'm wondering how budget and schedule for that predefined scope of the MVP was estimated.

When it comes to estimation for stories in the backlog:

What is your role in the project?

What are you concerned about: The estimation of the work they do or the amount of work they get done?

What's the development team's insight on why they tend to underestimate?

@Peter: "What was the Development Team's response when presented with evidence that they are apparently over-estimating their capacity, and repeatedly falling short of their sprint forecasts?   Did the team have any ideas or suggestions for improving their ability to estimate items and/or meet their forecasts?

@Tim,  the response from Dev Team, is that the underestimated complexity and Product owner/ User story has not clearly defined the expected result

If I understand correctly, the Dev team is providing feedback that not only are the items more complex than originally thought, but also that the items are lacking in acceptance criteria.

It is good to be able to identify where some of your pain points (issues) are.   The next step is to have a discussion about what can be done to improve the situation.

A few more questions for you:   

1. How can the creation and documentation of acceptance criteria be improved?   Acceptance Criteria should be a significant portion of your DoD.
2. Is the Development Team in full control of their Sprint Forecast (based either on all or a portion of the Product Owner offer), or is work being pushed to them according to a waterfall schedule (created when the least information was known about the project)?
3. Can the Development Team and Product Owner find ways to improve item refinement to reduce the amount of complexity and unknown nature of said items?

@Steven => "how budget and schedule for that predefined scope of the MVP was estimated"

A:  The product is just moving to a new technologies.  We used  past budget and duration as estimates.   my Role is Scrum  Master. My concerns are  more amount of work that is being produced. 

@Julian ..good catch.. My verbiage s/be more realestic estimates. The Dev team  s/know what how long a story can be "done"

@Olivier : Yes their DOD is "potentially shippable".   Code is merged frequently so that PO and review and either make adjustments as needed.  

@Tim : thanks for the feedback.  PO grooms the backlog  onto a sprint log , explains the overall goal  and he leaves the DevTeam  to decide the estimates /story points etc.  On start of this project,  I have clearly indicated to PO that he cant push more than they can handle.  Told the DevTeam, it their right to tell PO that if  certain items cannot be done  if they think  they don't have capacity.  Then PO has to complete reprioritizing US. that were dropped in that sprint plan. Oh yes the DOD is includes Unit  tests,  QA .run thru regression test suite before being deeemed Done and merged  to  Test Env for stakeholder review at end of sprint. to your 3rd question: I am struggling with this..  my job is not to undermine the PO/Dev Team..but to synthesis over all productivity  and team harmonization occurs for the overall ROI  the project. thats the reason, I am probing the community so that I can make an informed recommend to the team /stakeholder and players in the ecosystem.

PO grooms the backlog  onto a sprint log , explains the overall goal  and he leaves the DevTeam  to decide the estimates /story points etc.  

Peter, I believe one of the feedback items from the team was that the items contained poor acceptance criteria.   From your recent statement, it appears the items are being created and groomed by the PO in a silo.   Do you think there might be a correlation here?

From the Scrum Guide:

"Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items."

I have clearly indicated to PO that he cant push more than they can handle.  Told the DevTeam, it their right to tell PO that if  certain items cannot be done  if they think  they don't have capacity.  

The team continues to underestimate both their capacity, and the complexity of the items.   Perhaps if the team collaborated more with the PO during the sprint around the items (instead of waiting until Sprint Planning), this issue could be mitigated somewhat?   

You have given instructions not only to the PO but also to the team to respect the offer/forecast nature of Scrum.   I'm just curious if there have been any instances where the team has pushed back regarding the overloading of the sprint?

From the Scrum Guide:

"The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "Done" Increment."

And finally, this quote from you stood out to me:

my Role is Scrum  Master. My concerns are  more amount of work that is being produced. 

As a Scrum Master, your focus should be on Scrum, the Development Team, the Product Owner, and the organization as a whole.   It should never be a concern of yours that the team is not producing according to expectations, outside of helping the team identify and resolve issues impeding their ability to collaborate and produce.

@Peter 

My concerns are more amount of work that is being produced. 

My verbiage s/be more realestic estimates. The Dev team  s/know what how long a story can be "done"

What is the actual concern - the accuracy of the estimation for the forecasted work for a sprint or the amount of work they get done in a sprint?

For the first one, get together with the team and dig deep into what the actual reason for them estimating to low most of the time and let them come up with possibilities to solve this issue. Maybe the stories are to large, acceptance criteria to vague, refinement only done on the surface etc. The developers will know best. Maybe they are just afraid to estimate higher, because they feel a pressure to estimate lower. Of course, this will result in less work pulled into each sprint in the first place, but more stability in the long term. There's no magic trick to multiply a team's velocity.

And just in case that there is this kind of pressure and someone does isn't concerned about estimation, but the work they get done in a sprint: This might not be a sign of the team underestimating work, but those others underestimating the project, as the people's abilities working on the project are also part of the complexity of a project.

Thank you all for the feedback.  SCRUM on :)