Milestone Three

Primary Objectives:

  1. Go through class project mini Sprint 1: planning meeting, backlog refinement and grooming, construction, review meeting
  2. Use Azure DevOps for Scrum Agile processes
  3. Prove architecture and development workflow for class project
  4. Team project inception begins (week 1 of 3)

Overall Requirements:

  • Class Project:
    • Epics/Features/User stories in Azure DevOps, each with ID, effort, priority and description
    • Commit one user story per person, run 1 mini-iteration (sprint) to
    • Confirm architecture: minimal introductory site deployed on Azure, with database interaction, database deployed on Azure
    • Go through all Scrum meetings
  • Team Project Inception (Part 1 of 3). At least:
    • Mindmap or other brainstorming output
    • Vision description
    • Preliminary needs and features lists

Grade sheet

Tasks:

  1. Create project on Azure DevOps to coordinate our Scrum activities. Important things to remember:

    • Before you add any work items, make sure you're using the “Scrum” process. You'll have to change this since the default is “Agile”
    • Enable it to show Epics in Work Items. The default is just Features, PBI's and Tasks.
    • Invite your team members and make sure they can fully use the site.
    • We're not hosting our code here, so “Repos” won't have anything in it.
    • Add a project description on the Overview page
    • Lastly set up days/duration for 2, 1 week Sprints. Let's start them on Monday and ending on Sunday. You may have to adjust the allowed work days to do that.

  2. Populate your Product Backlog

    Go over your user stories for the class project that you identified during the inception phase last week. Which ones are really Epics? Features? Or just User Stories? Organize and then enter all of them into a your Azure DevOps project. Do the following

    • All items should show up in the Work Itmes page and should have the same structure as last week: Epics, broken down into Features, ...
    • Item state should be “New”
    • Make ID number, Priority, Effort, State and Title, in that order, visible in the backlog view
    • Assign priority values for each backlog item. "1" is for highest priority, and then arrange in descending order in your product backlog.
    • If you haven't already, decompose the highest priority Epic(s) into multiple Features, with multiple User Stories, and possibly Tasks, as is suitable for each story. You only need to do this for enough top priority items that will prove the architecture and reduce most of the risk of the project.
    • Assign an effort estimation for the highest priority backlog items. For our purpose we will only use Fibonnaci effort values of 1, 2, 3, 5, 8, 13, 21 where 1 is trivial (a 1/2 hour or so for one engineer) and 21 which will equate to a full sprint effort for one engineer. Each sprint is nominally two weeks in length, usually 20-30 hours work for each engineer. Epic stories will ultimately consist of multiple backlog item level user stories. Once a story is identified as an epic story, it may have a much larger effort value; but it then must be decomposed into many backlog item level user stories that each have at most a 21 point effort level.
    • All top priority User Stories (i.e. the ones you might do for the first 1 or 2 sprints) must have notes written in the Description section to clarify what is to be done.
    • Try to follow the DAD book's process for Iteration Planning on page 292, Chapter 14. As a team you are doing Just-In-Time planning and modeling of a solution for PBI's and tasks going into the Sprint.

  3. Sprint 1 Planning: Iteration planning, backlog grooming and refinement

    Try to follow the DAD book's process for Iteration Planning on page 292, Chapter 14. As a team you are doing Just-In-Time planning and modeling of a solution for PBI's and tasks to be committed into the Sprint. Hold a Sprint Planning Meeting and groom the class project backlog. Add a single user story, or suitable Tasks, to Sprint 1 for each team member. Remember to assign it to them in DevOps. This is a mini-iteration used for practice and will have the purpose of setting up a relatively simple version of the class project.

    Since this is just a simple version you may need to be a little creative with your User Stories for this one. We don't want the construction to be difficult or time consuming on this one. No real features yet. That's OK. The purpose of this is to run through the process. Next week we'll do some real features. You may want to break things down into Tasks, which don't have to be written in User Story format, and then divide the tasks up among your team members.

    Once in a Sprint, you should change the state of the user story to “Committed”.

  4. Sprint 1 Construction

    Run through this Sprint and create a very simple initial version of the application, deployed on Azure and having some database interaction. The database should be deployed on Azure. Make sure you go through the whole process on Azure DevOps and conclude the Sprint. Every team member must manage their own User Story and Tasks on Azure DevOps. Create new feature branches for all work and submit them using pull requests using our Git workflow. Merge develop into master only after all work from the sprint is finished. Publish from master. It's also a good idea to have a separate testing site deployed off develop that you can put up and take down at any time. Leave your main site deployed all the time.

    More:

    • When the PR is accepted and your work is merged into develop you can consider that user story or task to be done, so change its state in DevOps to “Done”, either manually or by dragging it to the correct column in Board's view. There's no formal testing yet but you must test your work manually. Don't submit a PR until your work is done and done. If you want your teammate to test it, have them fetch your branch and test. Don't do it through a PR.
    • If you're splitting up Tasks (under one user story) between team members you should share your work through feature branches manually and then have the person assigned to the main user story be the one to merge locally and then issue a PR. One PR per user story.
    • What does your burndown chart look like at the end of the sprint? What are good patterns for a burndown chart?

  5. Team Project (1 of 3 weeks)

    Select one of your ideas and go with it (assuming it's approved by your advisor). This will be the first pass at an Inception phase. Spend quality time with your group going through the first parts of Inception. You want to determine a really good overall vision for your project. Follow the roadmap from the class project. First create a Mindmap or other brainstorming diagrams that outline what you think your project will entail. Then write an initial description of your project vision. Then move on to a preliminary list of Needs and Features and possibly some requirements. Keep all these in your official team repo in plain text files (i.e. Markdown files are good) when possible. Be prepared to discuss the details of your work with your Advisor. In fact, give a little pitch of your idea and the details. There will be questions!