Agile #4 – Estimation and planning

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

Agile#3 – Generating user stories

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.

Agile #2 – User stories

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

Agile #1 – Gathering requirements

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.

Manager notes #6 – Manage a team

Managing a team is more than managing individuals. Being a manager is not about having the most technical knowledge.

Stay technical

  • you will always have to guide technical decision making
  • you must be seen as technically credible
  • you need to stay enough in the code to see where the problems are and to evaluate
  • if you stop coding too early in the career, you may never achieve sufficient technical knowledge

Debug dysfunctional teams

A dysfunctional team can be characterised as a team where its members are unhappy, they keep quitting, the product manager is frustrated and they keep missing deliverables. They maybe lack energy or enthusiasm.

  • if team is not shipping, it might be because of the tools and processes. Remove all the bottlenecks as poor tooling around release, heavily manual testing, features too big.
  • « the brilliant jerk » – a move to another team
  • the negative person – make it clear the behaviour has to change; if he’s unhappy help him leave the team on good terms; maybe he is not aware of his impact on the team
  • unhappiness due to overwork – support the team and help them with the work. Reduce and avoid overwork
  • lack of collaboration – gather feedback, create opportunities for them to hang out outside work

Act like a shield ?!

The team should be shield from distraction. Help them understand the key important goals and focus on them (however, let some of the stress reach to the team so they will get some context into what they are dealing with). On the other hand, don’t deny events and communicate information that might neutralise the impact on your team.

Humans need some context into why these goals have been set and what problems should they be working on to solve. They need to understand the consequences.

Take good decisions

  • get as much data as possible and create a data-driven team culture
  • look into the future and get a sense of where the product roadmap is going
  • review your decisions and run retrospectives for the processes

Manage conflicts

When managing conflicts:

  • don’t rely on votes
  • have clear set of rules to evaluate decisions
  • address conflict issues without cultivating dysfunction
  • don’t take it out on other teams
  • be kind, not nice
  • don’t be afraid
  • get curious

Advanced project management

You will help set the schedule for the team by estimating whether the team can do certain projects, how much work will be and if you have the right people to complete the work. You need to have a strong sense of the pace of the team.

  • there are 13 weeks per quarter, expect only 10 weeks of focused effort on the main projects per team member.
  • 20% for generic sustaining engineering work (testing, debugging, dealing with legacy code, etc)
  • say no in order to achieve goals
  • use doubling rule of software estimation
  • don’t be a telephone between the engineers and the rest of the company

Manager notes #5 – Managing people

As a new manger you must figure out your own management style.

The main tasks required to manage people:

Starting on a new report

Starting a new reporting relationship off in a right way means to get to know the person quickly so you can manage him best.

  • build trust and rapport – ask questions intended to help you get to know the aspects of the person that impact your ability to manage him well (how he likes to be praised, preferred method of communication, how you can tell if he is a bad/good mood, any clear career goals, any manager behaviour he might hate)
  • create a 30/60/90 – day plan – have a clear set of expected goals and create realistic milestones
  • encourage updating on-boarding documentation – reinforce the editing of the documentation by the new hire to reflect processes and tools that have changed since the last time
  • communicate your style and expectations – the team needs to understand your expectations and your style (how often you want to meet with them, how to share information)
  • get feedback – get as much feedback as you can. Don’t encourage people in this period to criticise the established processes in a way the team might feel attacked

Communicating with the team

  • have regular 1-1s – they are crucial. There are many styles of 1-1s:
    • the to-do list meeting – list of objectives to cover in order of importance
    • the catch-up – listen to anything your direct reports want to discuss but don’t turn it into a complaining session or therapy
    • the feedback meeting –
    • the progress report – when you have someone who is off on a side project that you are not personally overseeing
    • getting to know you – get the know the person reporting you as a human being in a sense of you want to show them you care about them as individiuals
  • scheduling 1-1s -respect the schedule
  • adjusting 1-1s – adjust time and questions for each person

Micromanager vs. Delegator

Micromanagement

  • junior positions and projects that go off the rails sometimes needs micromanagement
  • too much control; trust and autonomy are affected

Delegation

  • delegation does not mean abdication – when you delegate you are still expected to be involved as much as is necessary
  • being a good leader means being good at delegating

Continuous feedback

Continuous feedback means a commitment to a regular share of positive and corrective feedback:

  • basic understanding of the individuals on the team
  • observe
  • provide regular feedback
  • provide coaching

Performance review

360 model – a performance review that includes feedback from the manager, teammates, everyone who reports and coworkers, self-review

Cultivate careers

You need to make a case for someone promotion. Every company has its own promotion process. In general, people are moved forward by the process. The evidence: projects completed independently, participation and support, engagement in team meetings and team planning.