About Me

Steve Barrett Profile linkedin-logo-icon  twitter1

Steve Barrett – SPC, PMI-ACP, CSM, ICP
Perth, Western Australia

Digester, aggregator and practitioner of things that work.

Specialties include:

  • Agile Project Management
  • Agile methods including Scrum, XP, Kanban, Lean Startup etc.
  • Scaling agile in the enterprise
  • Agile Coach/Trainer/Mentor
  • Workshop Facilitation
  • Risk Management.

3 thoughts on “About Me

  1. Pingback: Five Blogs – 11 April 2014 | 5blogs

  2. Hi Steve,
    I am looking for some guidance on Components and Epics. Am having difficulty understanding the difference between the two. I have been working on projects using Agile framework; however, now I am getting more questions on why we’re not using the component level too. The Agile framework i have used to date includes: Product Backlog (has epics–> user stories) –> Sprint Backlog
    When would i use Component level too alongside epics?
    Looking forward to hearing form you.
    Thanks in advance.

    • Hi Anitha,

      Are you talking about Components generically or has this become topical as you are using Jira which enables you to create components and associate them to issue types?

      I will answer generically, components normally are a breakdown of your system/product, different components work together to create solutions in your system/product. Based on this (but also dependant on how your teams are organised – more on that later) I wouldn’t be looking to use Component in a hierarchical break down of a product backlog. Each item in a backlog is (eventually) expected to satisfy INVEST, that means it should provide valuable working software that in effect cuts across layers and components of your architecture. If you had backlog items that are components then you are more than likely not creating valued working software (just a part of the system that is not valuable yet). When implementing a backlog item that has been broken down to a User Story (that satisfies INVEST) I would expect the tasks involved to be working on/across components in the architecture.

      It looks like you have a hierarchy of epics to User Stories which sounds fine, you can create whatever hierarchy that makes sense for your delivery (another example might be Capability –> Feature –> Epic –> Story). The important thing is that it’s progressive elaboration of that product backlog, as things become prioritised and more important they progressively get broken down to smaller items in your hierarchy (Just in Time – JIT), like progressively breaking boulders to rocks to pebbles as and when needed (not all up front).

      The other point I made earlier about how your teams are organised… Ideally you are working with Feature teams, teams that have all the skills on the team to be able to provide working software through your architecture and across these components. Some organisations however are hindered as this is not how they are setup, they instead have component teams with people that specialise in particular components for the system/product. This means valuable working software can only be produced across more than one team creating dependancies that will make life much more difficult for the delivery of value and delay the required feedback loop. The goal here would be to break down these specialist teams and create cross-functional feature teams, this can be a journey for an organisation to address.

      I hope this helps.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s