The daily workflow

The daily workflow2018-04-12T11:37:47+00:00

Daily Team Workflow

Context

Summary

Provide a summary of this practice.

The Daily Workflow describes the major tasks in the Core Team’s working day. It applies primarily to the developer/user pairs as they convert stories into working software.

Purpose

What is the overall goal or intention of this practice?

The Daily Workflow is used:

  1. to ensure that inexperienced Agile teams (or new team members) understand how to approach the working day.
  2. to provide a basic framework for activity.

SLA

What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?

N/a. This ‘practice’ is only indicative.

Exit conditions

What must have happened or been delivered for this practice to be considered complete?

N/a.

Entry conditions

What pre-conditions must be met before this practice is used?

  • A developer/user pairing has been established.
  • The Iteration Backlog has been agreed & prioritised.
  • The iteration has begun.

Outline process

This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.

#StepInstructions
1Daily Stand-Up Meeting
  1. Review activity since last meeting.
  2. Agree day’s goals.
  3. Identify obstacles.
2Select story
  1. Select the highest priority item in the queue.
  2. Check the Story/Task Board for changes that may affect your work.
  3. Check the Improvement Board.
3Review story
  1. Read & agree understanding of the story.
  2. Review agreed Acceptance Criteria, etc.
  3. Check the Definition of Done.
4Code & configure
  1. Implement story with user.
  2. Continually test & review.
  3. When all tests are passed, refactor the code.
  4. Validate code against Definition of Done standards.
  5. Reintegrate final code with mainline.
5Update records
  1. Update Backlog.
  2. Update Story/Task Board.

Detailed process

#StepByOutputInstructionsNotes
1Daily Stand-Up MeetingIteration Lead.
  1. Review activity since last meeting.
  2. Agree day’s goals.
  3. Identify obstacles.
See ‘Daily Stand-Up Meeting‘ for the detailed process.
2Select storyUser.

Developer.

  1. Select the highest priority item in the queue.
  2. Check the Story/Task Board for changes that may affect your work.
  3. Check the Improvement Board.
Backlogs are normally structured sequentially in priority order, so selecting each day’s work should not be a problem.

Key issues:

  • Always check: priorities can change quickly & unpredictably.
  • Have the stories or development tasks your story depends on made the required progress?
    • If not, inform the Iteration Lead & select the next story from the Backlog.
  • Have the necessary foundational tasks been completed?
    • E.g., environments installed, tools set up, etc.
 3Review storyDeveloper.

User.

Agreed interpretation of story.
  1. Read & agree your understanding of the story.
  2. Review agreed Acceptance Criteria, etc.
  3. Check the Definition of Done.
  • Read through the story.
    • Has it changed since you last reviewed it?
    • Check with the user that they can represent actual users’ understanding of the story effectively.
    • Walk through the story to confirm that the developer & the user agree on its overall meaning.
    • Be especially careful with this step – conflicting assumptions & misunderstandings are common.
  • Review the story’s Acceptance Criteria.
    • And any supporting information – e.g., non-functional requirements.
    • Check the Definition of Done.
      • Are the Acceptance Criteria compatible with the Definition of Done?
      • What other requirements does the Definition of Done create?
      • Do you think the Definition of Done needs modifying to suit the story?
  • Check details with other team members, if necessary.
  • If the story is likely to take more than one day:
    • Agree interim goals for the first day.
    • Make clear what will still need to be done later.
    • Aim to complete full units of functionality each day.
4Code & configureDeveloper.

User.

Working software.
  1. Implement story with user.
  2. Continually test & review.
  3. When all tests are passed, refactor code.
  4. Validate code against Definition of Done standards.
  5. Reintegrate final code with mainline.
  • Always use a separate branch of the source mainline.
  • Helpful materials & resources are likely to include:
    • Existing system documentation.
    • Non-functional requirements.
    • Etc.
  • Set up any other contacts & meetings you expect to need.
  • This task should be repeated until both user & developer are satisfied.
  • Verification should test the software against:
    • The story’s initial description.
      • As a…, I need…, So that…
    • The story’s Acceptance Criteria.
      • Given…, When…, Then…
    • Other non-functional requirements.
    • The applicable Definition of Done.
5Update recordsDeveloper.Updated logs & boards.
  1. Update the Backlog.
  2. Update Story/Task Board.
  3. Update Impediment Board.
  • Update the backlog:
    • With changes to the story.
    • So other team members can identify any impact on their work.
    • … and the Product Owner can understand & communicate how each story is progressing.
  • Update the Story/Task Board:
    • So progress is visible.
    • And lack of progress too!
  • Report immediately new obstacles or opportunities.
    • To the Iteration Lead.
    • To anyone else who might be affected.
    • To anyone else who could help with the issue.
    • Don’t wait for the Daily Stand-Up Meeting.

Issues & risks

What are the key concerns in making a success of this practice?

  • This Daily Workflow applies primarily to the developer/user pairs who turn stories into working software.
  • Although stories are deliberately designed to be at a high level of granularity (i.e., a small, manageable element), they are not developed in true isolation.
    • While developing an individual story, the Iteration Planning process, plus general team awareness, should ensure that the user and developer take into account the rest of the Iteration Backlog, any epic the story is part of, and any wider considerations.
    • In other words, story implementation is like doing as jigsaw: the immediate problem – finding out how to deal with a single piece – is only ever part of a larger picture.
  • Stories often take more than a single day to complete, of course. Where this happens:
    • Start each new day by fixing the overnight defects.
    • Try to complete whole units of functionality each day.
    • Refactor at least daily (but ideally much more frequently).
    • Re-integrate your code at the end of every day.
    • Update the Backlog & Story/Task Board daily.
    • Run automated tests every night.
  • A standardised Daily Workflow is possible only because the Iteration Lead:
    • Protects the developer/user pairs from interruption & distraction.
    • Manages all communications between the team and its stakeholders.
    • Manages the risks, obstacles and improvements on which smooth delivery depends.
    • Prevents uncontrolled changes to the backlog.
  • Where the day is disturbed, it should only be by pre-planned events such as:
    • Showcases.
    • Meetings with External Team members.
    • Retrospectives.
    • Unavoidable interruptions such as organisational events, meetings with external agencies(e.g., regulators), etc.
  • Where disturbances begin to disturb the daily workflow regularly, the team should develop methods either to avoid such events or to absorb them efficiently.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?