Skip to main content

DAD Inception Phase Workshop Agenda

Disciplined Agile Delivery (DAD) realised the reality of the projects and introduced back phases to Agile community. Whoever works in a project based company, especially a project based company where projects are usually less than one year in length and each are for different clients, understands the reality of Agile in such environment. When you start working on a new project for a new client, it is essential to go through a phase that you get to know each other better, to understand the business purpose of the project, to understand the scope of the project, to know what are the high level architecture and what technologies are going to be used and who is the initial team, and if funding is available and also when things must be delivered and to whom.

In answering these questions you may need to meet with different people, run couple of workshops and brainstorming sessions. And this is called Inception Phase. As DAD is more like a goal oriented decision framework and not a prescriptive process framework, it defines certain goals that you must achieve before concluding inception phase. these goals are:

  • To form initial team
  • To develop common vision
  • To align with enterprise direction
  • To explore initial scope
  • To identify initial technical strategy
  • To develop initial release plan
  • To secure funding
  • To form work environment
  • To identify risks

When I first started to learn about DAD several years ago, It some how felt familiar approach, not because I had experience managing projects based on RUP, and DAD phases seemed to be like RUP phases. But because the goal oriented-hybrid-none prescriptive approach simply made sense to me. Most of Agile methodologies and processes assume you are in a product based company, or Projects are long term and there are enough capital to continuously improve. But, how about many other projects that deadlines exist, capital is rare, scope is defined and the project is not the product or service of the company. In these environments, an inception phase is in fact very essential. Although, this does not mean that Inception Phase only applies to such circumstances. 

One of the challenges I faced working with teams and clients for inception phase was the agenda and the length of the inception phase workshop. In order to make it easy for my team to replicate the process. I prepared an agenda that can be used as plug and play for inception phase. Depending on the situation, you may not need all these agenda topics or you may need to do them more than allocated time or even less. But, this agenda seems to be sufficient for a project length of up to 10 months and a team of 5 to 7 people. 

Inception Phase Workshop Agenda


Here is the agenda of an inception phase workshop that we follow at Actum. We run inception for new projects with existing clients as well as completely new projects with new clients. We also use inception phase workshop during tender with some of the potential clients. 

  1.  Prepare the room: Make sure the following is prepared, ready and available: 
    1. Water, Coffee and Fruit.
    2. White board marker, Flipchart marker, two sizes of sticky notes, pen, Flipchart, and whiteboard. 
    3. User Story or Feature Board: A place to capture user stories. 
    4. Risk Board: A place to capture project risks as you go through inception.
    5. Need To Be Clarified Board: A place to write things that you and others may need to clarify. Sometimes, you may need things from people who are not in the room with you or more time is needed to find the answer. 
    6. Modeling Board: A white board or several pages of Flipchart to capture initial high level architecture models, UX and other visual modeling and artifacts. 
    7. Business Objectives Board: A place to capture business objectives.
    8. And do not forget about projector. 
  2. Introduce the workshop and Agenda, and answer questions that participants may have.
    1. Duration: up to 20 min
  3. Review Business Objectives: To understand business reasons behind project, how to know if the project is successful from project sponsor’s perspective.
    1. Duration: up to 90 min.
    2. Product Owner (maybe with other key stakeholders) introduces project business objectives and answers any question team may have. 
    3. Team Lead and/or Business Analyst captures business objectives on the board so everyone is aware of them during the inception workshop. 
  4. Identify Personas and User Roles
    1. Duration: up to 60 min. 
    2. Some may ask for more time to create perfect personas, but the goal is not to create perfect personas or final user roles. The goal is to have good enough roles and/or personas so you can use them to create some objective user stories later during the day.
    3. You may ask everyone to come up with several user roles, then review them together and aggregate or remove duplicate ones. (Facilitate it as brain storming session, so all opinions are welcome.)
  5. Capture a list of user stories and features
    1. Duration: up to 90 min
    2. With the team, help product owner (and stakeholders) to write as many user stories as possible. Try not to be so restrict about the format of user story statements. 
    3. While you or some of your team members are helping product owner(s)/stakeholders with user story and feature brainstorming, Others can review written user stories and check them with business objectives, user roles, technical risks, and even think about high level architecture. 
    4. Write each user story or feature on one sticky note and put them on user story board. Also, capture risks, initial modeling and other information on related boards to refer to them later.  
  6. Group User Stories and Features: To identify Epics and Themes
    1. Duration: up to 60 min
    2. Identify and group Themes.
    3. Group related user stories (functional and/or nonfunctional) together under each theme.
    4. You may also create some sub-groups to identify Epics. 
    5. While doing the above, you may write or update some acceptance criteria, discuss UX and application architecture.
  7. Prioritise User Stories and Features.
    1. Duration: up to 90 min
    2. Now that you have an approximate grouping of stories and some high level modeling. It is time to prioritise the Themes, Epics and Stories from business perspective. 
    3. At this stage, you only want to know what is important from business point of view. You will have a chance to reprioritise again and reflect risks and technical dependencies. 
    4. You may need to help product owners (and stakeholders) with prioritisation. Especially if they do not have enough Agile experience, you may help them to priorities themes first, and then epics and leave the user stories for later. 
    5. Again, feel free to write and update some acceptance criteria, discuss modeling, risks and capture things that need clarification "in parallel" to prioritisation. 
  8. Story Decomposition: To know more about reasons behind stories and remember even more stories . 
    1. Duration: up to 90 min
    2. By this time, you may have many stories and features on your board. But,  you may find it useful to discuss little bit in more details. 
    3. It is better to review the stories with the team and see if you can identify stories that are too general, to vague or too large  and decompose them into smaller and more specific stories. 
    4. and again, while doing this keep updating risks, maybe clarify some of the things you capture on To-Be-Clarify Board and do some modeling "in parallel".
  9. Refinement: To review priorities and decomposed stories and refine the order.
    1. Duration: up to 90 min
    2. Review the decomposed stories or features, move them between groups (themes/epics) if needed. Update priorities if needed. 
    3. Prioritise stories from business point of view.
  10. Estimation: Two of the goals of Inception are Release Plan and Funding. And you need to size the work in order to reach to a rough release plan and be abel to ask for budget from business. 
    1. Duration: Up to 240 min
    2. Either use planning poker or magic estimation to estimate story points for each user story. (I personally prefer planning poker as you will have a chance to talk and discuss more. But if time is not on your side then feel free to go with Magic Estimation.)
    3. The point is not to be 100% accurate. The goal is to reach to a range estimate. You may estimate with 50% confidence at this stage. 
    4. And keep discussing acceptance criteria, risks, modeling and architecture. 
  11. Define Definition of Done (DoD).
    1. Duration : up to 30 min
    2. DoD is very important at this stage. Because your estimation of delivery will depend on it. 
    3. Discuss and agree with the team and product owner on a reasonable definition of done. 
  12. Decompose Stories to task: To be able to forecast velocity.
    1. Duration: up to 120 min
    2. Decide about the length of your iteration. (let’s assume 2 weeks)
    3. By now, you should have very good idea about what is the scope of the project and what is the high level architecture. 
    4. From the top (highest priority) select a user story and decompose it into tasks in order to meet DoD within iteration period. 
    5. Estimate tasks based on hours. 
    6. Continue to decompose stories into tasks until your capacity is full for one iteration period.(let’s say you have a team of 5 people, each work for 8 hours per day for 10 days, then your total capacity for one iteration is 400 hours approximately.)
    7. But, it is better to consider only 6 hours of productive work per person. And keep the rest 2 hours for unplanned activities and breaks. 
  13. Prepare Release Plan
    1. Duration : up to 180 min.
    2. This may be quick activity, but it also depends on how much details your stakeholder expect from you. 
    3. From the previous activity, you should have a rough idea how many story points the team can deliver per iteration. This is your forecast Velocity. 
    4. Sum up all story points of all user stories, Then divide the total number by the forecast Velocity. And the result will be the total number of Construction iteration. 
    5. If business wants to go live with certain features at certain point of time, then you may need to create more than one release plan. And therefore, you may need to add extra weeks for Transition Periods. Also, you may need to add couple of days for next rounds of Inception Phases - but your goal is to have shorter and shorter inception phase as you learn more about the project. Ideally, no more inception phase. 
    6. As the estimations are with 50% confidence, you may add 30% - 50% Project Safety buffer to your release plan. Again, you should reach to a range estimate to communicate with your stakeholders. If the Range estimate is not acceptable yet at your organisation or with your client, then make sure that you spend more time on story point estimation, capture more acceptance criteria, and try to estimate 2 times - once with 90% confidence and once with 50% confidence and use the difference as your project safety buffer. 
    7. With all the above info, you should be able to construct your first release plan. (as you move forward in the project you will update the release plan, so do not be so religious about it.)
  14. Estimate Project Budget. 
    1. Since you have your release plan based on story points and team allocation, you can easily calculate total project budget based on your team hourly or daily rates. 
  15. Finalise Project Vision Document
    1. Put all the information captured during the inception phase workshop into one document to present to project sponsor for project approval.

Things to pay attention to

Here are some points to take into consideration when running an inception phase workshop:

  • Make sure everyone who is attending the inception workshop knows in advance what is this workshop about and why you are running it. You may need to run some training and introduction sessions first, specially if people were not familiar with the concept or agile way of working. Some may disagree, but I found it very useful to have training before the workshop to reduce waste during inception workshop.
  • The same agile and lean mindset must be applied here too - Reduce Waste, and only Work on things that deliver value to your stakeholders and the team, and nothing else. 
  • Set time-box for the whole activity of inception workshop to control your desire to get into more details, after you have enough data and information. 
  • It is also good to set time-box for each activity, but feel free to change them during the inception. Especially if the project is new. But, do not extent the whole inception workshop period. Keep the inception goals in mind and work toward them.
  • Always, keep in mind that each activity is here to help you to move to the next step. So, when you have enough data and info, Stop and move on to next step. Inception phase is not the time for perfecting the architecture or analysis. You may have time to do these during the project construction. So keep it simple and move forward with just enough information.
  • Make sure, nobody is waiting for someone else during inception workshop. I usually tell to people I coach that everyone should be working on something at the same time, work in parallel. Below are couple of pictures of some of our inception phases, you see that at each session people are working and nobody is waiting for anyone else.

Architect Owner and one team member discussing technical architecture with Enterprise Architect, while Business Analyst  discusses some of the written stories with a Domain Expert. Team Lead, Product Owner and Another Domain expert discussing other set of stories. 

User Experience Specialist, Product Owner and Team Lead work on new user stories, while the rest of the team are reviewing and discussing them. 
  • To avoid wasting time during inception workshop, you may agree on a flow of work, and agree on who does what. 
  • This Agenda for inception phase workshop is very intense. It is designed to be done in less than one week. Make sure, there is enough oxygen in the room, good light, enough stationeries (sticky notes, pens, markers, flip charts, whiteboards), fruit, water and vitamin!
  • People may get tired or frustrated during such an intense workshop. So make sure you have enough breaks and watch the mood and keep the atmosphere positive. (15 min break every 90 min could be sufficient)
  • Continues documentation. Because at the end of the inception phase you will need to prepare and finalise project vision document, try to prepare it from the beginning and update as you go forward. You may also, use a shareable and collaborative document with the team, so everybody can participate and collaborate in preparing the document. 
  • Modeling and Artifacts. As much as possible try to draw and write things on the board in a readable format, so when you take picture of your models and writings, they are readable by others. It is highly recommended to not recreate these models again in some other software unless it is really necessary. the goal is to reduce waste and one waste is rework.
  • Before Inception Phase workshop, you must make sure that you have an initial idea about the roles and responsibilities of your team and client. This may change later, but it is important to assign some roles before the workshop. 
  • One challenge for people when starting to use Lean and Agile is the concept of "Good Enough". If you review all the activities above, they tend to be finished when you have enough data and information. There is a threshold that you must find to understand the good enough concept for your work. There are certain goals that you must reach, and anything beyond those goals does not add more value but consumes more time and money. Good Enough means, you have enough data to move to the next step, not 2 steps ahead or 5 steps, but only next one step. 

Depending on the project type and your relationship with client, you may even go lighter with inception phase and keep it simpler and less intensive as long as you reach the inception phase goals. And yes, the ultimate goal is to not even have inception phase if possible. 




Comments

Popular posts from this blog

Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle

I was thinking what the title of this blog post could be, I had couple of options to select from and decided to use a title that uses Disciplined Agile (DA 2.0) Lifecycle. Other options for titles were: Moving From Scrum to Kanban From High Performing Scrum Teams to Hyper Performing Kanban  The bottom line is that at some point you may want to move away from Time boxes to a flow of work and service oriented teams and improve performance and throughput without massive and sudden organisational change.  As always, I only share my experience and this may not apply to all situations, context is important.  Another reason that I selected “Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle” as the title, was that for many it is a question mark how to navigate through DAD life cycles. and I think this blog post could be one of the ways to navigate.  Context: A Delivery Team started with Type A Scrum with 2 weeks Sprints. After a while,

Stay Fitter

1st edition of Fit for Purpose: How Modern Businesses Find, Satisfy, and Keep Customers from David J Anderson and Alexei Zheglov was published in Nov 2017. They wrote the first edition in 7 weeks during summer 2017. I had a chance to provide feedback to them as they were writing and editing their chapters. The book basically talks about what a product and service is made up of, how customers measure the product or service and what metrics company managers must apply at different levels to be always fit for customer purpose (the Why's of the customer). If I want to summarise the book in one statement, it would be like: Align your business to how your customers measure your product and service. When I was reading the chapters, four guys came to my mind: Peter Drucker, Jack Trout, Eliyahu M. Goldratt and Clayton Christenson. The book reminded me of Peter Drucker; because he once made a profound observation that has been forgotten by many, his observation goes like this: "B

Escalate, Escalate, Escalate!

What is escalation at organizations? Is it a way to solve problems? Is it a way to report things? Is it a way to put more pressure? Is it a CYA technique? What is it? How do you use it at your organization? How other colleagues of yours use escalation? Really, think about it and observe. At IT service companies, leadership measures the performance of IT Help Desk by number of escalated work items over a period of time. The less escalation the better . The reasons are simple: It is cheaper for companies if an IT Help Desk Specialist resolves an issue than an experienced technical specialist at one or two level higher. This is simple math, one gets $X and the other get $X*2 And when client gets result fast, he/she will be happier. So, less escalation equals happier client in IT Services. Client raise an issue, IT Help Desk Specialist resolve it, BOOM, Next! At organizations, It is amazing (sadly) to see how much lower level managers escalate problems, that they and thei