1 / 21

Steven Borg | Co-founder & Strategist, Northwest Cadence Anthony Borton | ALM Consultant, Enhance ALM

05 | Define End Value for the Software Iteration . Steven Borg | Co-founder & Strategist, Northwest Cadence Anthony Borton | ALM Consultant, Enhance ALM. Module Overview. Elicit requirements Estimate requirements Document requirements Prioritize requirements. Elicit requirements.

josef
Download Presentation

Steven Borg | Co-founder & Strategist, Northwest Cadence Anthony Borton | ALM Consultant, Enhance ALM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 05 | Define End Value for the Software Iteration Steven Borg | Co-founder & Strategist, Northwest Cadence Anthony Borton | ALM Consultant, Enhance ALM

  2. Module Overview • Elicit requirements • Estimate requirements • Document requirements • Prioritize requirements

  3. Elicit requirements

  4. What the Study Guide says… • Elicit requirements. • defining project requirements • reviewing and clarifying requirements • defining acceptance criteria • defining UI platform requirements (Web, mobile) • assigning a business value

  5. Documenting lightweight requirements

  6. Estimate requirements

  7. What the Study Guide says… • Estimate requirements. • managing and assigning effort estimates (assigning story points) • resizing user requirements into smaller, manageable pieces • executing task breakdown • estimating the requirements baseline

  8. Story Points • Story points are an arbitrary measure of the effort required to implement a story. • It is the team’s estimate of how hard the story is. • Team specific. Doesn’t translate between teams well. • Generally not related to days, or tied to other time based intervals. • Often uses a rounded Fibonacci sequence (1,2,3,5,8,13,20,40) • In Scrum, story points are often used to by the Team to measure the effort required for a product backlog item • Sprint velocity is based on story points • Estimated in a number of ways, including planning poker • In simple terms its a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort. • In simple terms its a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort.

  9. Resizing requirements • In order to deliver value continuously and receive rapid feedback, requirements must be sufficiently small. • Think: Smallest possible item that provides business value • Business value could be customer value, reduced risk, validated learning, revenue or other key metric. • Thoughts: • Generally not everything in a 200 page requirements document is required. • Small requirements that can be shipped independently allow completely new ways of working

  10. Decomposing requirements in TFS 2012

  11. Document requirements

  12. What the Study Guide says… • Document requirements. • defining acceptance criteria • listing requirements • adding requirement details • designing UI storyboards

  13. Documenting requirements in TFS 2012

  14. Extending PowerPoint Storyboards

  15. Prioritize requirements

  16. What the Study Guide says… • Prioritize requirements. • identifying requirements that are critical path • identifying must-have requirements • enabling the entire team (including customers) to participate in requirements prioritization • identifying dependencies

  17. Identifying must-have requirements • Ensure anything designated as must-have truly must be had in order to meet a “minimally viable product” • My experience: about 75% of most “must have” requirements generally aren’t actually required to deliver customer value or achieve validated learning • Several tools exist for classifying requirements: • MoSCoW (Must have, Should have, Could have, Would like) • Regardless of tool, hardest part is ruthlessly reducing the batch size of delivered code to the truly “must have” requirements

  18. Critical Path • The critical path is the longest necessary path through a network of activities when respecting their interdependencies • Work breakdown structure (list of all activities) • Time estimate for each activity • Dependencies between activities • TFS does not calculate a critical path. MS Project does. • MS Project can sync with TFS • fidelity depends on the field mapping file in the process template • <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Scheduling.StartDate" ProjectField="pjTaskStart" PublishOnly="true"/>

  19. Using MS Project with TFS

  20. EXAM BEST BETS • Although the prep guide seems to stress formal requirements management, keep a lean and agile mindset for test success. • Scrum intro earlier in the day still applies strongly to this section • Many ways to prioritize requirements • In Scrum, prioritization is done by the Product Owner • Understand, however, the strengths MS Project brings if a critical path must be identified, or predecessor/successor relationships need to be defined.

More Related