Loading ...
Sorry, an error occurred while loading the content.

CMMI (VAL) in SCRUM

Expand Messages
  • Carlos Antônio Menezes de Albuquerque
    Dear All, I would like try to map CMMI (VER , VAL and PPQA) in SCRUM. First i started a little map to VAL process area. Could you help me to complete the
    Message 1 of 2 , Dec 1, 2004
    • 0 Attachment
      Dear All,

      I would like try to map CMMI (VER , VAL and PPQA) in SCRUM. First i
      started a little map to VAL process area. Could you help me to complete
      the informations described below? Are they corrects?. I am SCRUM beginner.

      Regards

      Carlos


      ---------------------------------------------------------


      VAL (CMMI PA) vs. SCRUM



      SG 1 *Preparation for validation is conducted*

      *SP 1.1-1 Select products and product components to be validated and the
      validation methods that will be used for each.*

      * *

      *Validation method:* Sprint review meeting

      The Team prepares what will be presented in Sprint review based on
      Product Backlog. Functionality that isn’t “done” cannot be presented.
      Artifacts that aren’t functionality cannot be presented except when used
      in support of understanding the demonstrated functionality

      *SP 1.2-2 Establish and maintain the environment needed to support
      validation*.

      Functionality should be presented on the Team member workstations and
      executed from the server closest to production—usually a quality
      assurance (QA) environment server

      *SP 1.3-3 Establish and maintain procedures and criteria for validation.*

      The work product must be “done” to be presented - Complete as mutually
      agreed to by all parties and conforming to an organization’s standards,
      conventions, and guidelines. When something is reported as “done” at the
      Daily Scrum or demonstrated as “done” at the Sprint review meeting, it
      must conform to this agreed definition.

      *SG 2 The product or product components are validated to ensure that
      they are suitable for use in their intended operating environment.*

      *SP 2.1-1 Perform validation on the selected products and product
      components.*

      The purpose of the Sprint review is for the Team to present to the
      Product Owner and stakeholders functionality that is done and get
      validation. **

      *SP 2.2-1 Analyze the results of the validation activities and identify
      issues.*

      At the end of the presentations, the stakeholders are polled, one by
      one, to get their impressions, any desired changes, and the priority of
      these changes.

      Stakeholders can identify any new functionality that occurs to them as
      they view the presentation and request that the functionality be added
      to the Product Backlog for prioritization.

      The Product Backlog is updated with found issues
    • Deb
      Hello Carlos! What you have written does seem generally accurate for Scrum, IMO. ... the ... used ... I wonder if it is worth mentioning that the team is free
      Message 2 of 2 , Dec 1, 2004
      • 0 Attachment
        Hello Carlos!
        What you have written does seem generally accurate for Scrum, IMO.
        I have two comments, see below:

        --- In scrumdevelopment@yahoogroups.com, Carlos Antônio Menezes de
        Albuquerque <camenal@t...> wrote:
        > SG 1 *Preparation for validation is conducted*
        >
        > *SP 1.1-1 Select products and product components to be validated and
        the
        > validation methods that will be used for each.*
        >
        > * *
        >
        > *Validation method:* Sprint review meeting
        >
        > The Team prepares what will be presented in Sprint review based on
        > Product Backlog. Functionality that isn't "done" cannot be presented.
        > Artifacts that aren't functionality cannot be presented except when
        used
        > in support of understanding the demonstrated functionality

        I wonder if it is worth mentioning that the team is free to validate
        the requirement or the software with the Customer at any time during
        the Sprint. This increases everyone's understanding of what is to be
        delivered, makes it more precise as work progresses.

        >
        > *SP 1.2-2 Establish and maintain the environment needed to support
        > validation*.
        >
        > Functionality should be presented on the Team member workstations and
        > executed from the server closest to production—usually a quality
        > assurance (QA) environment server

        I wouldn't say "usually" - perhaps others will contradict me?

        For various reasons, moving the software to QA in time for the demo
        could be problematic. 1) it hasn't been approved yet by the customer,
        so it's not necessarily ready for testing (I've seen a customer ask
        for rework in the next sprint, considering the feature undelivered);
        2) some teams do not "deliver" software after every Sprint, but
        instead have a Release Sprint; 3) some teams do not work with a
        dedicated QA team so this distinction may be artificial.

        Perhaps there is another way to describe the kind of environment
        optimally used?
      Your message has been successfully submitted and would be delivered to recipients shortly.