Étiquette : agile

How do you plan and estimate in Agile?

Planning

• a multilevel planning – release planning (several months), iteration planning (several weeks), daily planning
• frequent – not a lot of details in the beginning
• just enough, just in time –
• adapt and replan – as things change, we are open to change the plan

Estimation

• Effort vs duration – ideal days (developer days) = will take to complete a story if you work uninterrupted
• Accuracy vs precision – instead of going into details so you can estimate « with precision », you can use « sizing buckets » (Fibonacci series, XS, S, M, L, XL) and put the stories there
• relative vs absolute sizing – story points vs ideal days
• estimation styles
  • Simple – free form
  • Planning poker
    • time consuming
    • uncover misunderstandings
    • collective ownership
    • engaged
    • good for backlog grooming
  • Card sorting
    • useful when estimating large number of stories together

Velocity

• The amount of work done by the team in a sprint
• It is used for selecting story in the upcoming sprint
  • the last sprint velocity
  • average of last sprints
  • range
• it can be adjusted

Release planning

• Fixed scope – How long it will take?
  • you need know the sprint length, the velocity
• Fixed date – What can we deliver?
• How to select stories:
  • story map
  • value market
  • learning
  • short feedback loop

Release tracking

It indicates when the release will be done or if we are on the track for a particular release. There are three ways to do that:

• release burn-up
• story board
• cumulative flow diagram

Where do the user story come from?

User story writing workshop

• Write as many user stories as you can for the selected theme
• Invite the product manager, the scrum master, the dev team to make sure that everyone is participating and understanding what we want to build
• It can last from a few hours to a few days
• Identify the following:
  • who are the users, understand them
  • what functionality we want to build from them
• create the backlog with all the stories:
  • detailed appropriately – more details for the stories that will be handled in the next future
  • emergent – it should evolve continuously
  • estimated – predict/plan your releases
  • prioritised – pick the top item to work on

Story mapping

• What does a story mapping help to:
  • Discover user needs
  • organise and prioritise story backlog
  • understand and communicate user needs
  • plan releases and development
• How to create
  • understand the problem, what is the benefit to the software
  • outline the activities an user will do in the system (what are the steps for each activity)
  • explore variations – happy path + alternatives the user have, capture the details, look for exceptions, consider other users, involve others
  • release meaningfully – what is the impact of that release, what is the success criteria for that release.

The main component of an use story are the 3C’s:

Card

– what do you want, as a higher level

Conversation

• Who is the user, what he wants and why?
• What happens outside software? What can go wrong? (Happy path and exceptions)

Confirmation

• Acceptance tests
  • How does the Product Manager validate the user stories once they are done? How will we demonstrate it at a product review? What will we test that is indeed done?
  • Use user language, don’t be too technical
  • What the user wants to do and not how it should be done

Stories can be written at many levels of abstractions:

Epic, Feature, Capability – Right sized for business

User story – right sized for users

Dev story, small user story – right sized for dev

Spikes

These stories are needed when you have to do some research work/knowledge gathering. It should be time-boxed and a clear definition of done. Most of the time, it is not part of the production code.

What is a good user story?

INVEST: These are guidelines to be used to create better user stories but don’t let them come in the way of building effectively.

• I – Independent
• N – Negotiable
• V – Valuable
• E – Estimable
• S – Small
• T – Testable

Build what the user wants

A good user requirements process will help us build the software the users have in mind and creates a shared understanding among all the shareholders of the product.

Conversation – primary form of communication

• Developers and business work together toward the development process
• Just Enough – Just In Time (Progressive refinement) – contain the 3C (the card, the conversation, the confirmation)

Adaptive – Discover user needs vs. collect user needs

We don’t know the needs, we will discover them. The requirements will change.