Project-Based Scrum - is it normal to structure Scrum Teams around projects?



  • My company suddenly introduced a new change to our workflow. They call it Project-Based Scrum (they claim that this Scrum is the real Scrum by the book).

    So how this thing works:

    1. There will be multiple projects
    2. each project will have different team members
    3. after the project is done the team will be disbanded
    4. each project will have different stand-up, grooming, and planning meetings
    5. A Product Manager will handle multiple projects
    6. Idle team members will focus on a maintenance/bug board
    7. Tech leads will lead the Project teams and will select the team members

    Does anyone here know what company uses this kind of Scrum? Or it is true that this kind of Scrum is the real Scrum?

    I'm confused about how this Project-Based Scrum will work.



  • This is not Scrum.

    Scrum has a definition in the Scrum Guide. This is a living document - it's reviewed, maintained, and updated based on feedback from people using it and experiences. This is "real Scrum".

    Now, what the Scrum Guide provides is a framework. There are a couple of rules. You can add things to Scrum. In fact, you almost have to add things to Scrum since it doesn't get into the details of how to do most of what is suggested. However, you cannot remove any of the events, roles, or artifacts as the end result would no longer be Scrum. That doesn't mean that removing something is bad, it's just that you shouldn't be calling the end result Scrum anymore.

    The Scrum Guide is short - the November 2019 edition (the most recent as I'm writing this post) is 19 pages. That 19 pages includes a title page, a table of contents, and the bulk of the last page is acknowledgments and credits - the guide itself is roughly 16 pages of content. If you aren't sure what Scrum is, the guide is the best starting point.


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2