Skip to content
Permalink
f2505d31f3
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Go to file
@aa7401
Latest commit 54c0d7f Feb 11, 2020 History
1 contributor

Users who have contributed to this file

Agile Processes

By this stage you should have completed your agile planning and have a word document containing a feature roadmap with each feature described in the form of a user story. In this lab you will be implenting the top feature from this roadmap.

Planning

This should be carried out using a whiteboard or flipchart. Nominate one member of your team to be the Product Owner, they will take charge of these tasks.

  1. Take the top user story from your roadmap and, grouped around the board or chart, discuss how the feature will be seen by the end user (The user interface design). You should end up with an agreed design that should be verified by the lab tutor.
    1. If you already know the tech you will use (such as React/Ant Design) you should ensure that the interface makes use of these components).
    2. If you have experience of UI Design you should ensure the design is suitable.
  2. Now, as a team you need to decide on the architecture of the solution (the different components and how they should communicate with each other. You should use one or more simple diagrams to describe this.
  3. Finally you need to define the message-passing between the components:
    1. What protocol(s) will be used?
    2. What URL/topic structures will be used?
    3. What data (values and format) will be used?

At the end of this section take a picture of all the notes and designs and post to MS Teams. Clean any whiteboard you have been using and dispose of any flipchart pages.

Task Breakdown

This activity should be done using the Issue Tracker tool provided by GitHub. Nominate one member of your team as the Scum Master, they will take charge of these tasks.

Now that everyone in the team has a clear idea of the outcome they need to break the problem down into a series of small tasks:

  1. The Scrum master should create a team repository:
    1. In the GitHub Organisation create a team (use the team name allocated) and add everyone to this team.
    2. Create a repository in the organisation giving it the same name as your team.
    3. Under settings > collaborators and teams, add the team to allow everyone to have access, set the permissions to write.
  2. Working together, use the Issue Tracker to make a list of all the tasks that need to be completed to ensure the feature is delivered. Make sure all the subject experts in the team are involved in this.
  3. . The Scrum Master should select one of the tasks and use the Labels > Edit Labels option to create four labels with four colours:
    1. 1 hour (white)
    2. 2 hours (green)
    3. 3 hours (orange)
    4. 4 hours (red)
  4. The Scrum Master should now read out each of the tasks and everyone should use the process of Planning Poker to vote on how many hours the task should take. Use the fingers of one hand to register your vote.
    1. If everyone agrees, use the appropriate label to record the estimation on the task in the issue tracker.
    2. If there are differences ask the person with the highest score and the person with the lowest to explain their rationales then everyone votes again.
    3. If the consensus is that the task will take more than 4 hours, the subject expert(s) need to split it into two smaller tasks which are voted on.
  5. The Scrum Master now adds up all the hours from the task cards:
    1. Divides this by the number of days the team have allocated themselves (2 weeks in this case) to determine the daily burn rate which should be communicated to the team.
    2. Uses an MS Excel spreadsheet embedded in MS Teams to construct the Burndown Chart.

Task Allocation

This activity should be done using the Project tool provided by GitHub. Nominate one member of your team as the Scum Master, they will take charge of these tasks.

  1. The Scrum Master should now add a new Project to the repository, calling it Kanban.
  2. They should add three columns to this board:
    1. Not Started.
    2. In Progress.
    3. Completed.
  3. All the tasks should be dragged into the first column (Not Started).
    1. In the project (Kanban) board, click on the Add Tasks button.
    2. Drag each of the issues into the Not Started column.
  4. Each member of the team chooses one task they want to work on:
    1. They drag the issues into the middle (In Progress) column.
    2. They allocate it to themselves.

Development

This activity is iterative, you will complete as many cycles as are needed to complete the user story.

  1. As a team decide on which days you will be getting together to work on the feature:
    1. The Scrum Master should create a (recurring) calendar event in Teams.
    2. All team members should accept the invitation.
  2. Each member of the team now starts work on their chosen task. When this is completed:
    1. They drag it to the last column.
    2. Set its status to Complete.
    3. They make a note on the issue card as to how many hours it took.
  3. Now they drag another task to the middle column and assign themselves to it, repeating this process.

Daily Stand Up

  1. At the start of every day spent on the work your team should hold a short 15min daily stand up meeting.
    1. From this they can calculate the burn rate since the team last met.
    2. They should also use this information to update the Burndown Chart.
  2. At the start of the meeting the Scrum Master takes the team through the project status (burndown rates/chart).
  3. Each person in the team speaks for 60 seconds:
    1. What have they completed since the last meeting?
    2. What are they planning on completing before the next meeting?
    3. Are there any issues the Scrum master needs to help them resolve? If any are identified the Scrum Master makes a note for these to be resolved later, after the meeting.
  4. After the meeting, the team get back to work and the Scrum Master talks to anyone who raised issues and helps them to resolve these, possibly by asking someone else in the team to help.