User Tools

Site Tools


changesinrequirementsinagile

This is an old revision of the document!


Topic: Changes in Requirements

Steps:

Q1: What happens to development that is done?

Q2: Can we allow changes this late in the game?

Q3: Who’s responsibility and what are some alternatives?

Discussion:

  • Whatever is done in the 3wk sprint should be delivered – ALWAYS!
  • Developers shouldn’t have to worry since requirements should be frozen before it is developed
  • Sizing may discover problems and tickets can and should be able to be worked and broken down
  • Users own the $ and change their mind on deliver – delivering functions that are no longer needed are bad
  • The PO reads the user stories to development and answers questions
    • Development should focus on the what
  • PO should be working 1 to 2 Sprints ahead so they can plan
    • It is legitimate to change before developing, since there are more and more discussions
  • Backlog grooming should include everyone
  • Changes should be made to 21’s to break them down and discuss more in detail
  • Changes also come up that can change a 13 to a 21
  • These tickets should shift to the next Sprint
  • Once more discussions are held, tickets need to get to an 8 or something that fits in the epic
  • Whole team contributes with refining but it is the PO’s responsibility to keep this in check
    • The PO has to communicate, know, understand the impact
    • Architecture POV should be available during design
  • In true agile we NEVER freeze requirements, until development (for two weeks) starts
  • The PO and SCRUM master have to work closely on the backlog, have to know what is coming and see impact on current work and completed work as well.
  • Requirements /Code freeze should be set dates, published
  • Dev is not tied to a release, some development can go beyond

Q4: What is the impact of changes on other tickets?

  • The key is constant collaboration
    • Don’t go one day without talking as a team
    • This goes beyond the stand-up meetings
  • During a three week Sprint there are three planning meetings (SCRUM master, PO and BA) can talk and breakdown changes
  • If there is a critical change add a SPIKE to your sprint
    • Emergency releases can come in any time
    • If management says stop you stop
      • Agile says you are not supposed to but this is real life
    • For each stop sprint:
      • The PO needs to determine impact of change
      • Discuss and share the findings and the results

Q: When a SPIKE happens, how do you handle motivation and momentum?

  • Agile embraces change
  • Development team should still demo what they have
  • One of the biggest fallacies in Agile is that you don’t plan…you MUST

Q: The biggest issue here is why are business requirements changing so often?

  • Change the PO!!!
  • It is the PO responsibility to shield their team from changes
  • One way is to have the team deliver “as is” then the next Sprint time delivers the changes
  • Lots of free wireframing tools – this helps to give everyone (who is visual) a good idea of what is to come and if everyone has a different picture in their mind
    • Wire-frame proto-type tool
    • Generates functional specs document
    • Quick changes to documents
    • Earlier the changes – the less it “costs”

Q: who does wire framing?

  • Should have a UX team
  • SCRUM collaboration needed
  • There are also lots of tools that can assist with specifications and also generate code from acceptance criteria
  • PO should NOT be promising the dates;
    • this would tie our hands to make changes
    • PO shouldn’t promise dates – setting timeframes is a team responsibility
    • PO can identify which quarter or general timeframe
    • SCRUM master should facilitate don’t participate **some disagreement here
    • PO is the SME but needs PM for dates
  • BA/PO should have a close relationship

Q: What tools do we use for Agile?

  • Most use Jira, Word, Pivotal Tracker,
  • Suggestion: Don’t get hung up on the tool
  • It is just a repository for information for your process
  • You can learn any tool and make it work for your changes

Additional Challenges:

  1. Adding Scope
  2. New Hardware Requirements not included; More automation
  3. Outside current team skillset
  4. Sizing?
  1. Costs of adding scope just need to be understood, it is going to happen
    1. Decisions should be made at PO level and everyone informed immediately
    2. Sprint zero analysis of change; some teams retool the entire application
    3. Deliverables from this sprint are the analysis
  2. PO is not an architect, nor are they sometimes technical, this can’t be avoided
    1. Sizing these types of users stories cannot be done as tasks
  3. Team can shift to accommodate, but should have an architect, UX, infrasture support for company
  4. Sizing a user store or task is based on points
    1. Points do not equal hours
    2. Work effort, risks and complexity will make one 8 different from another 8
    3. If a work item gets too large, break it up
      1. Don’t use tasks for this as each one should be tested differently
  5. Example: Importing excel spreadsheet is a typical requirement…. This can’t be done in one sprint, BA should work with PO to break this into, inputs, validations, ux etc.

Summary: Changes cannot be stopped, the business is always changing. Just ensure you have an analysis of the impact including the cost. If the CSPO has had training and has some basic tools - which are critical for success of everything, especially requirements this shouldn’t be a big problem, just another change that is planned for.

PO’s are SME’s – the most knowledable, they can be the PM since they are organizing, which would give them more access to timelines, if the PO doesn’t know the business, or the project this could be a reason for so much change.

Some companies, that have PO’s that just check-in, or are disconnected from the project are going to experience these issues, train!!! Ship them off to classes, sit with the users, learn the application, once the PO take charge the project will run smoother for the teams, and there will be more successful deliveries.

Tips:

  • Co-locate
  • Provide tools to communication/talk everyday!
  • Make changes before the Sprint then freeze
  • Commit to a daily stand-up to identify impediments or problems
  • A Sprint commitment is on-going; work on code that go to Production if needed
  • It will be a problem if you can’t fit dev/test/UAV in one Sprint
  • Get into smaller more focused teams; by functional, delivery etc.
  • Ask for feedback, figure out the root cause and do something about it!

changesinrequirementsinagile.1404817470.txt.gz · Last modified: 2014/07/08 04:04 by admin