Milestone Five

Primary Objectives:

  1. Class project retrospective
  2. Team project inception concludes
  3. Team project construction begins

Overall Requirements:

  • Class Project Retrospective artifacts
  • Team Project Inception (Part 3)
    • Updates of documents
    • Development guidelines/team rules/requirements/... “Contributing to Project” written in Markdown format and linked from project Git repo welcome page
  • Team Project Construction
    • Backlog refinement/grooming
    • Select user stories to prove architecture early in iteration
    • Select user stories for each team member for full iteration

Grade sheet

Sprint Review Sheet: .docx or .odt

Tasks:

  1. Class Project Retrospective — hold a retrospective meeting with your team. There needs to be a time set aside for every team member to contribute. Let each person say what went well and what didn't. Be positive, say what went well. When something didn't go well, still be positive. Treat it as a problem that needs to be identified and then solved. Take short notes as you hold your meeting and then write up a short summary of the following:
    1. Recite the prime directive of retrospectives
    2. Conduct a Safety Check
    3. What did you learn from the Sprint?
    4. What still isn't going right?
    5. What can the team do better during the next Sprint? Make a specific Action Plan.
    6. Are there any items that need to be brought up with someone outside the team? (i.e. in this case the instructor)

  2. Team Project Inception (III) — some time has likely passed since you worked on some of the inception tasks. Take the time to update these to their most current form. Did you decide on doing something and didn't include it in your model diagrams? Have you thought of more that needs to go into your Architecture drawing? Add to it or redraw it.

  3. Team Project Inception (III) — now that you're about ready to begin construction, you should settle on some procedures that the team has agreed (amongst themselves) to follow. Basically, to be a part of the team, what do you need to do or know? Write all this up and include it in a very visible way on, or hyperlinked from, your Welcome page on Bitbucket. All these should be in Markdown format and available by clicking on links from your Welcome page. Here are some things I've thought of.

    • A description of your project on your Welcome page. You've got it figured out, and have a Vision statement, so put it there for any visitors to see. Explain your project. If it helps, pretend this is an open source project that someone far away might want to contribute to. Explain it to them. Here's a very brief version I wrote up for a CS 490 class: WOU 3D Scanner. And here's a far better version from a past team: StarTech
    • Guidelines and Contributing code to the project. How to contribute. What rules to follow when writing code? Database? Should you always make the primary key just ID or use the style of ProductID? One of them better be to write XML comments for all public methods! Here's my too short example from the same class: Guidelines
    • Clearly list all team members
    • What software construction processes or lifecycles are you using? Do you have a link to any team pages?
    • Any Team Rules? Team song?(← required) Team cheer? Dance moves? Mascot? 😁
    • List of tools used, including versions. Continuous development/deployment? Link to your deployed site?
    • List of everything that needs to be installed by Nuget, including version numbers. (Fine if it's blank for now)

  4. Team Project Construction — hold a backlog refinement and grooming meeting. Now, right before your first real, 2-week, Sprint is the time to get your backlog into shape. Your goal is to have a nice looking, orderly backlog. Priorities look good. The top priority items have effort values. Lots of good descriptions, acceptance criteria and modeling artifacts (in your repo of course). (Acceptance criteria will not be required until Sprint 2.) When you have it looking good:

    • Select and commit user stories for Sprint 1. This is a two week Sprint, so you have quite a bit of time. Be sure to have the first few user stories be ones that prove your architecture and get everything running smoothly before trying to add features. If your project will have individual user accounts then now is the time to set it up. Here's a writeup that should help: Using ASP.NET Identity

      You need to have enough stories in the Sprint so that each team member has 18 effort points per week. That's 18 * 2 * 4 = 144 effort points total if you have 4 team members. Feel free to use tasks. They can have effort points too, that add up to the total for the user story they're part of. You can track this even if DevOps doesn't.

    • Ideally you want each team member to select his or her own stories. For this first sprint, go around and choose the first week's worth of stories for each person. For the second week, choose them on-the-fly in an amicable way. Assign in DevOps for the first week prior to your meeting with your advisor.
    • Print out your Sprint 1 Backlog and include it in your binder. It needs to show ID, Effort, Priority, Assigned To and Title for each item (just print the backlog view after expanding all Epic/Feature/PBI/Task items). This is what you are committing to deliver at the end of Sprint 1.
    • Take a look at the Sprint review sheet (linked above). Fill it out one for each developer before the Sprint Review meeting next week and bring to the meeting. It needs to have everything filled in (story ID's, effort values, ...) except the Completion Points. You'll be graded in part on finishing what you committed to.