User Stories

In Agile, the project workload is broken down into user stories and estimated, prioritized, and assigned. A user story, or often just called a 'story', is an abbreviated description of a feature of a system, told from the user's perspective. There are two forms you can use:

• Long form = A sentence that describes exactly how the user interacts with the system. "When I go to the login page, enter my credentials and click the login button, the home page appears."
• Short form = A minimal set of words that hint at the underlying interactions, such as "Login".

Iterations

Opposed to dividing the project schedule into distinct phases like in waterfall workflow, in Agile the project schedule is broken down into iterations with a fixed size of usually two weeks. For example, a 1-year project could have 26 iterations of 2 weeks each. An iteration is not a mini-waterfall with specific phases that occur only once and in a particular order, such as planning -> design -> implementation -> testing. In an iteration, all phases are performed continuously, allowing for overlap and frequent revisits. For example, if a design problem arises during implementation, you simply redesign immediately and then continue implementing.

Goals of the Initial Iteration

• Development Environment Setup (source code repository, CI/CD, tools and configurations etc)
• Story List Creation: In co-operation with the stakeholders, generate a short list of stories.
• Effort Estimation: Assign each story a number of points representing the estimated implementation effort. See here.
• Provisional Design setup of the software architecture based on the story list.

Goals of Every Subsequent Iteration

Start of Iteration

• Each iteration begins with the Iteration Planning Meeting (IPM).
  • The purpose is to determine and prioritize stories to be implemented in the current iteration based on estimated effort and business value.
  • The IPM allocates about 1/20 of the total iteration time. For a two-week iteration, this translates to a half-day IPM.
  • The whole team and the stakeholders attend the meeting.
• Story Deck Update: Stakeholders explain their needs, which are written down as stories on cards and collected in a story deck.
• Estimate Stories
  • The developers estimates the effort of the stories and write it as points on each story card.
  • Stakeholders rate stories based on their estimated business value. Some sample models for expressing business value are: important / unimportant (story), low / medium / high (business value), or even in points, similar to effort estimates. This value is also written on the story card.
• Story Deck Ordering: The order of the story deck is determined by the return on investment (ROI), simply the cost-benefit ratio between the estimated effort and the expected business value. The story with the best ROI should be at the top.
• Implementation Plan
  • The goal is to determine which stories should be implemented in the current iteration.
  • Determine the expected velocity for the iteration:
    • At the start of the first iteration, the team has no data on the team's actual velocity. Therefore, the team estimates which stories they think can be implemented in the first iteration.
    • For subsequent iterations, the team expects the velocity of the current iteration to be the same as the velocity of the previous iteration, as this is the best guess.
  • Stakeholders select cards from the top of the story deck so that the sum of the points of all the selected cards matches the expected velocity. The stories on these selected cards will be implemented in the iteration. Remember that some stories may depend on other stories that need to be implemented first.
• Story Deck Evolution
  • Stories Evolve: Solved stories are removed from the Story Deck. As the project progresses, new usage requirements may emerge and be added as new cards to the Story Deck. Stories could also split or merge.
  • Estimates Evolve: Estimated effort and business value are affected by the evolution of the project. Therefore, stories need to be re-evaluated and the story deck re-ordered on a regular basis, i.e. in the IPMs.
  • Keep All Stories in the Deck: There may be stories that do not currently have a favorable ROI and are not worth implementing. They remain in the story deck because there is a chance that their estimated effort and business value will change over time, making them worth implementing later. Conversely, some stories may become irrelevant over time as their estimated ROI decreases.
  • Project End: If the story deck has no stories with a ROI that makes them worth implementing, the project ends.

During Iteration

During iteration, the team assigns and implements the stories just selected by the stakeholders in the IPM.

• Story Assignment: Immediately after the IPM, the developers meet and assign stories to each developer that they will be responsible for. Managers don't assign stories to developers, see Bill of Rights, but let developers negotiate among themselves who does what.
• Writing Acceptance Tests: Ideally, in the first half of the iteration, the testers should complete the acceptance test before the corresponding stories are implemented. In the second half of the iteration, they should start writing acceptance tests for the next iteration. The testers work half an iteration ahead of the developers. More details can be found here.
• Focus On Story Completion: Better to finish a few stories than to manage a lot of half-finished stories.
• Premature End: If the team has implemented the stories in an iteration earlier than expected, they pull new stories from the top of the story deck to make use of the remaining time.

Finalizing Iteration

• Demo Meeting:
  • Story Demonstration: Short meeting with the stakeholders to demonstrate newly implemented stories, 1-2 hours maximum depending on iteration size.
  • Passing Tests: Show that all unit and acceptance tests have passed, including those from previous iterations.
  • Demo Server: Ideally, stakeholders should be able to interact with the latest release of the system on their own, for example on a demo server separate from the production server. This also prevents developers from being tempted to hide things that do not work.
• Progress Update: At the end of an iteration, sum the points of each completely finished story and add that value as a data point to the agile charts. Unfinished stories and all their points are ignored and moved to the next iteration.
• Iterations do not fail: Initial velocity estimates are often overly optimistic and therefore higher than the actual measured velocity. The goal is to provide a realistic view of team productivity, not an accurate prediction. Iterations don't fail; they adjust the velocity prediction.

Story-Driven Development

In software projects, there may be many interdependent stories to implement, so the final design will be very complex and impossible to accurately predict in advance. Therefore, the initial design planning of waterfall is likely to fail. The solution is to implement the stories sequentially, as described above, even if it means refactoring the previous design frequently, which is why this approach is called story-driven development. It breaks the big complex design problem into many small but manageable chunks.

Even when working more informally or alone, it makes sense to have a story deck. It reduces the mental load of having to design everything in advance, and allows you to focus on the current simple story that needs to be implemented.