Proposed Solutions for Items not yet on Sprint Backlog
In my current company, we have the following events during a sprint.
> *Story Time 1 - BA discusses the requirement to the Dev Team, happens multiple time during the whole sprint
> *Story Time 2 - Dev Team discusses the Proposed Solutions, Testing Ideas and Hour Estimates, happens few days after Story Time 1
> Backlog Refinement - PO, SMEs and Leads discussing the final priorities based on teams proposed solutions, testing ideas and hour estimates
> Sprint Planning - locking in items to be part of the sprint backlog and creation of Sprint Goal
> Daily Stand-up
> Sprint Review
> Sprint Retro
Given all these events, are we doing it based on the Scrum Guide? Are we violating any pillars of Scrum or Agile Principles?
By contrasting your team’s implementation with the Scrum Guide, what observations would you make yourself? How do the “events” you describe compare, and the roles you mention? What about rules - should items be locked-in, for example? Where there are discrepancies, what problem are they meant to solve?
Actually, this is not the way I've known Agile and Scrum. I have just recently joined a company as a Scrum Master, and they have just implemented this process a few weeks or months before I started.
It's good that collaborations, whichever you want to call it, happens before the Sprint Planning. However, I don't believe that the development team should think of specific proposed solutions (as in document the specific classes and methods they will be changing, or a detailed coding strategy to implement an item, or create test scripts that will be followed during manual testing) before the team decides to include on the sprint since priorities, requirements, clients needs and/or market can change. Creating detailed propose solutions and test cases for items not yet part of the sprint is not exactly aligned with the principle "Simplicity--the art of maximizing the amount of work not done--is essential".
I think you make a fair analysis, and it seems like you are in a position to make your own critical assessment. Perhaps the issue to be focused on is not so much the “violation” of Scrum’s pillars and agile principles, but whether or not Scrum is being implemented well.