A Blog About Agile from Davisbase Consulting

Becoming Agile is the Davisbase Consulting blog about all things Agile. It features regular posts by our staff, whose diverse expertise and backgrounds enable us to offer fresh perspectives and insightful observations.

Check out some of our favorite entries by visiting the top posts page, and be sure to subscribe by RSS feed or email to keep up-to-date.

Agile Q&A: Extra Sprint Capacity



The Question: What should we do with extra capacity during Sprint Planning sessions?

The Answer: It depends. Isn’t that always the answer?




Before we dive into the response to this question, lets take a moment to review a few things about capacity and sprint planning.

  1. Teams measure capacity in hours. (Wondering what to consider when calculating an individual team member’s capacity? Check out the Capacity Planning Worksheet we have in the Agile Tool Kit.)
  2. Comparing tasks’ hour-estimates to the team’s available capacity to ensure authenticity. This helps the team avoid overcommitment.
  3. It is incorrect to pull a partial set of tasks for a backlog item. The goal is not “full utilization.” If the team will not complete the user story within the coming sprint, then the team should not start on it early.

It is quite common for teams to have “left over” hours,unallocated time at the end of a sprint planning session. In a perfect world, the team would have an item small enough that within the hours remaining they could complete all tasks. We all know that Agile teams live in an imperfect world.

So, what to do? Here are 4 great ideas for how to use your extra capacity.

  1. Pairing for Quality
  2. Pairing for Cross-Training
  3. Refinement
  4. Refactoring


Pairing for Quality

You can think of this as traditional pairing. Putting two team members together to gain efficiencies in quality. Two sets of eyes on one task allows both the right-brain and left-brain to engage simultaneously. Dual perspectives increase precision and offer a systems-thinking lens to the activity. This allows for enhanced execution and assessment of overall quality. While it may seem inefficient on the surface, studies show the reduction in rework outweighs the cost of pairing.

Consider promiscuous pairing when allocating capacity. Expand pairing beyond two team members with the same expertise. (e.g. Pairing a developer with another developer.) Cross-discipline pairing has proven to be beneficial for teams as well. It is also the perfect segue to the second recommendation.

Pairing for Cross-Training

There is a spectrum of specialist → generalist. High-performing, cross-functional teams are not comprised of all specialists. If they were, then swarming and task sharing would be much more difficult. Strong teams have the right level of specialty in certain disciplines and also include individuals with general knowledge and understanding useful for many activities. (Consider reading The Life of Pi blog post by Tom Wessel for more information on growing this capability.)

Prevent bottlenecks and increase the ability for team members to take on tasks outside of their traditional area of responsibility by using extra capacity for cross-training. Testing activities are a great place to start; exceptional Agile teams are efficient and effective at swarming testing activities. That means every team member should develop expertise in the discipline of quality assurance.

You may also find it useful to pair developers with skills in varying technologies and languages. This provides opportunities for professional development and mentoring while team members increase their skill-sets.


Getting a Story Ready” highlights that teams should avoid pulling an item for Sprint Planning unless it is “ready” for commitment. Backlog depth and ‘readiness’ are separate topics, but it is safe to say there is always backlog refinement to do. Leveraging extra capacity for refinement is a way to pay-it-forward and ensure future sprints will come and go with fewer impediments and gotchas.


Every system has technical debt. Extreme Programming (XP) practices tell us Refactoring is key to technical excellence. Agile Principles state technical excellence is essential for agility. If technicians on the team have extra capacity, use your available time to refactor a piece of code and make it better. The effort now, will make maintainability, scalability, and agility a lot easier in the long run.

What are your ideas for using extra capacity? Please leave your thoughts below!

Task Planning

blogimage_task-planningWithin the Agile community, the use of User Stories is a very popular method of building, categorizing and prioritizing components of work. The approach follows a very simple and easy to understand structure that teams use in order to build value for their respective customers. User Stories, when written correctly, can be understood by stakeholders, customers, line of business managers and the teams that will build value. This structure, which has worked well for many organizations is a way to help bring consistency and alignment across the enterprise; up to and including actual customers. In addition to User Stories, many teams decompose their actual work lists into items called Tasks. For new and even some experienced Agile teams, tasking stories can be confusing and, at times, burdensome. The purpose of this article is to address some of the common concerns around tasks from two viewpoints (theoretical and practical application). The intent is to provide you, the practitioner, with information that can help you in your Agile journey at the individual, team and even organization level.

Task Planning Top Five

Davisbase strives to develop teams that deliver value. Organizationally, task planning is a value based activity that provides teams with a tremendous amount of visibility. This visibility provides the team and organization with a high degree of transparency in regards to the actual activities that are needed in order to create valuable applications. As you move forward in your respective task planning activities, we’d like to share our top five reminders:

  1. Task Planning is done by the team
  2. Task Planning activities are for the team
  3. Create a task planning approach as part of the team’s working agreement
  4. Wherever possible, tasks should be broken down into units of work that can be accomplished in a day
  5. Tasks should be specific enough to be understood by multiple team members

Who are tasks for?

When teams begin to discuss and determine the best way to complete User Stories, they are already creating a sequence of events (initially verbally) that they will follow in order to accomplish the intent and desire of the User Story. For many team members, the process of writing their approach down via “tasks” is a very logical process to follow. Creating tasks and assigning them to a User Story will give the entire team the visual representation that they deserve in order to complete the work. As such, organizations should always encourage that tasks be written by the team, given the fact that tasks are for the team. It is natural and common that individuals outside of the team may understand the tasks (i.e. ScrumMaster, Product Owner, DBA, Architect, etc.), yet it’s always important to know who the tasks are for. Tasks are for the team.

Anti-pattern: As coaches, we’ve seen examples where tasks are written by the “leads” for the team. This should be considered an anti-pattern in that teams deserve the chance to self-organize and create their own work approach. “Leads” are important to teams, yet these members should write their own tasks and encourage others to do the same. Of course, there will always be exceptions to this statement, but make sure that the team has the opportunity to have the discussion.

What are the right kinds of tasks?

Teams have the freedom and responsibility to determine the best way to complete their work. As such, the right kinds of tasks will be depicted by the team on a story by story basis. Ideally, tasks should be specific enough to allow the team to recognize that a specific increment of the story has been completed. In some aspects, tasks may be tied back to the acceptance criteria that was written for the story itself. In addition, many teams will create a task structure as part of their team working agreement. An example of a task structure could include items like:

1. Development tasks
2. Peer Review tasks
3. Code Review tasks
4. Development unit test tasks
5. Quality tasks
6. Quality test tasks (manual, automated, etc.)
7. Review and acceptance tasks

Anti-pattern: For those of us coming from a project management viewpoint, we’re always looking for structure and consistency. It’s natural for us to want to create process, but we should always remember that the team’s own the tasks, just like they own the commitment. Encourage teams to create their own working agreements and task structures, but realize that each team is different and not all User Stories will have the exact same task structure.

What is too generic?

Tasks, as defined and written by the team, should be specific to the individuals working on the task and/or the team at large. Writing tasks is repetitive on a story by story basis and is an activity that will continually take place for the teams. While many teams create tasks and assign those tasks to team members, some teams write tasks that are specific enough to be picked up and work on by one or multiple people. Making tasks specific should be considered a best practice because the specificity will provide the team with necessary information in order to execute the work. Avoid writing generic tasks like this real life example below wherever possible:

1. Code story
2. QA task
3. DEV only task
4. QA only task

Anti-pattern: Agile teams strive to have all work visible, including tasks. While the tasks are certainly for the team, generic tasks can provide a false sense of security to both the team and anyone else who looks at the tasks. The false sense that can be derived is that not enough discussion has taken place by the team in order to determine the best approach for completing the story. Writing specific tasks can and will alleviate this concern.

What is a well-written task?

Well written tasks can be understood by multiple people on the team. As coaches, we believe that tasks have value and that the value is recognized incrementally as the User Story moves through various states (eg. defined, ready, in process, completed, released, etc.). An excellent best practice is encouraging task review (where applicable) as part of the Sprint/Iteration Planning process. Many teams may begin their work by writing standard tasks together and then splitting off into different areas to write additional tasks. Yet, those same teams will always come back together in order to review the tasks that have been written.

Anti-pattern: Don’t rely on team leads or SME’s to write tasks for the upcoming Sprint/Iteration. Active participation should be anticipated and encouraged by anyone who will be doing actual work on the User Stories.

Should they be estimated in hours? If yes, how many?

paperclipsFor teams that are new to an Agile mindset, many coaches will recommend that tasks be estimated in hours. The primary reason for this approach is to allow the team the ability to compare their tasked hours against their available hours for the upcoming Sprint/Iteration. This is an important activity that will help the team make a determination if they can commit to the body of work that has been provided by the Product Owner.

In addition, many coaches believe that tasks should be broken down into units of work that can be completed in less than a day. This is an excellent approach for new teams, yet we’d like to offer another viewpoint by saying, “Encourage teams to break down tasks into the smallest unit possible that provides value”. In our experiences, we’ve found that tasks are still items that can be completed in less than a day; yet understanding and thinking about value helps many people take their understanding and appreciation for the work completed to higher and higher levels.

Finally, some organizations have gotten to the point where they no longer estimate tasks in hours. These are usually found with very mature teams that have worked together within a very specific organizational culture. For those, the concentration is truly centered around value creation and value recognition throughout both the organizational hierarchy and via the customer community.

Anti-pattern: Avoid forcing teams to write tasks that must be completed in a work day. This will stifle the team on many different front. Encourage task creation that provides a solid understand of how the problem will be addressed. Encourage team members to determine the “best way” to solve the User Story. And finally, encourage team members to write tasks into specific items that have incremental value towards the successful completion of the User Story.

Are they just for one person?

As mentioned above tasks are not always just for one person. Teams that use both pairing and peering approaches will structure their work in such as way that more than one person will work on a task at a specific point in time. In addition, some teams don’t assign each and every task to a person prior to making a commitment and then executing against the commitment. Therefore, some tasks may not have one owner…they may have multiple owners. It is important to note that many of the tools in the open market don’t allow tasks to be assigned to multiple people at the same time. Some organizations have circumvented this issue by creating general users within their systems that represent two or more people.

In addition, it’s very important to understand the team member skill composition mix (generalists, specialists, generalized specialists). An awareness of this structure will be very beneficial in understanding which tasks should be assigned to a specific person versus those that may be assigned to multiple people. For some, this may seem like an intermediate to advanced concept. If you’re new to “tasking,” see how many of those tasks can be assigned to just one person. That will definitely get the conversation started in the right direction. You will find that many of our experiences will assign tasks to just one person. At the same time, the exceptions to the rule help to better understand the dynamics of the team and will help skills develop and organizations mature.

Keep push your own Agile limits and remember, “championship teams are not created when it’s perfect outside”.

15 Questions – Markers of Quality Sprint Planning Sessions

15 Questions – Markers of Quality Sprint Planning Sessions

Curious how to put a coaching point-of-view on evaluating a Sprint Planning session? Our team uses the following set of 15 questions to gather observations and assess trends over time.

  1. What Sprint is it?
  2. Were All Team members present?
  3. How long was the session planned for?
  4. How long did the session take?
  5. Were ALL team members engaged and committed to the outcome?
  6. Was the Product Owner available, engaged, and committed to the team’s success?
  7. Were backlog items refined and ready for Sprint Planning?
  8. Did the team define a sprint goal (or theme)?
  9. Did the team define capacity in hours?
  10. Did team members break down each backlog item into a detailed task plan?
  11. Were tasks right-sized to start and finish in a day?
  12. Did the team rationalize capacity against detailed task estimates?
  13. Did the team commit to their Sprint Plan?
  14. Did the team proactively identify dependencies among tasks?
  15. Did the team proactively identify potential impediments that may occur during the sprint?

A little commentary about each question…

What Sprint is it?
e.g. Sprint 4 This is important to track so that you can associate these observations to other metrics and information.

Were All Team members present?
When considering this, think about not only attendance of team members, but the appropriate co-location. The commitment made during Sprint Planning should be made collectively by all team members.

How long was the session planned for?
This is most likely tracked in hours, rounded to the nearest quarter hour. More mature teams will not need as long for a Sprint Planning session, however, new team may take as many as 4-6 hours to complete the session. Keep in mind, if you are planning for the session to last 5-6 hours, be sure to allow for a break.

Teams that have well-refined backlogs do not generally take more than 1-2 hours for Sprint Planning. When sessions run longer, that is an indication that backlog items are not ‘ready.’

How long did the session take?
Again, track this in hours, rounded to the nearest quarter hour. Look for trends such as consistently running over, or not taking up all the time allotted. Just because a session is planned for 4 hours, doesn’t mean you have to use all 4 hours. It’s finished with the objectives have been achieved. And don’t forget, its OK for the session to be longer than expected. The entire team needs to agree to extending the duration.

Were ALL team members engaged and committed to the outcome?
Each team member should participate in this session equally. Here we are interested in understanding if team members are committed to the desired outcome from the Sprint Planning session.

Was the Product Owner available, engaged, and committed to the team’s success?
Sprint Planning is essentially the moment a backlog item’s scope is locked down. As team members identify tasks it is inevitable that final questions will come up in relation to acceptance criteria and what is in-scope for the story. As a result, the Product Owner should be available and engaged in the session to ensure the team is constructing a plan for the right product increment.

Were backlog items refined and ready for Sprint Planning?
“Ready” for Sprint Planning can mean a lot of things. e.g. Backlog Items: are written in good form; have Acceptance Criteria that define the Product Owner’s needs; are discussed and understood by the Team; are decomposed from Epics into small Stories that can be delivered in one Sprint; are estimated by the Team in Story Points; are prioritized in rank-order by the Product Owner; have needed supporting documentation.

bookCheck-out this previous blog post on what ‘ready’ means: Getting a Story “Ready”


Did the team define a sprint goal (or theme)?
e.g. Complete the registration feature. A sprint flows well when the work is synergistic. If all backlog items are somewhat related then the tasks will naturally coordinate and the team will encounter less context switching as the sprint progresses.

Did the team define capacity in hours?
Before the session starts, team members should have thought through their individual capacity to commit to work. The determination should take into account planned vacation, non-team meetings and events, team collaboration and planning sessions as well as natural inefficiencies in work (about 20%). The facilitator (likely ScrumMaster) can then sum the numbers to determine the total team capacity.

Check-out the Capacity Planning worksheet within our Agile Tool-Kit to help team members think through their individual capacity in advance of the Sprint Planning session.

Did team members break down each backlog item into a detailed task plan?
Backlog items are historically decomposed into individual tasks. Ensure that enough tasks are planned to cover all items called for by the team’s Definition of Done. While backlog items are sized relatively using points, tasks should be estimated in hours in order to enable a team to make authentic commitments. This list of backlog items, tasks, and hour-estimates becomes the team’s Sprint Backlog or Sprint Plan.

Were tasks right-sized to start and finish in a day?
Humans are naturally inefficient creatures. So its safe to say that an 8-hour task will take more than 1-day to complete. Shoot for breaking down tasks to a 4-6 hour increment so that team members can commit and complete each day during the Daily Stand-Up. At most, use a 12-hour task (2-days of work).

Did the team rationalize capacity against detailed task estimates?
Consider responses like: On Target, Over-committed, and Under-committed. Sprint Planning is not magical, and teams should not waste time trying to make capacity and task estimates match up exactly. The goal is to best utilize the capacity available and avoid overcommitment as much as possible. Try to always come within 5-8% of the team’s capacity.


Look for an upcoming Agile Q&A Post about what to do with extra capacity.


Did the team commit to their Sprint Plan?
The ultimate objective of a Sprint Planning session is a commitment to deliver an increment of work. At the end of the session Team Members should look at the holistic plan and make an official commitment to deliver.

There are 2 aspects of the commitment. 1) Team Members committing to one another that they are going to band together to get the work done. 2) Team Members committing to the Product Owner that they will have something ready to demonstrate at the end of the iteration.

Did the team proactively identify dependencies among tasks?
Whether they are dependencies between tasks or external dependencies with other groups and teams, the identification and tracking of dependencies associated with the sprint is critical to success. In fact, looking at the critical path of tasks for each backlog item and analyzing dependencies will help a team further assess whether or not they are making a realistic commitment.

Here is a quick tip: For critical tasks, assign a “Must Start By” date. This will help know if stories with dependencies are on-track for closing out the backlog item.


Did the team proactively identify potential impediments that may occur during the sprint?
Teams that think ahead about impediments are less likely to encounter them. Experience tells us that task planning naturally uncovers potential impediments. It’s best to go ahead and capture that list so that you can work to resolve them before they even occur.

15 Questions in 2015

It’s a new year, and in 2015 we will be launching a new content series on our #BecomingAgile blog – 15 Questions. Each of the posts in this series will offer a set of 15 questions you can use to evaluate the maturity of your role, team, program, or organization.

We’re not taking a slow approach to this either. Check back tomorrow for the first in the series, 15 Questions – Markers of Quality Sprint Planning Sessions.

For now, here are 15 quick questions to help you be set up for a 2015 of learning!

  1. Are you registered for our monthly #BecomingAgile newsletter?
  2. Have you signed up to attend any of the free monthly webinars worth 1 PDU?
  3. Do you need to scale Agile practices across your organization? Then a Leading SAFe class might be for you.
  4. Are you aware we provide free downloads and helpful tools in our Agile Tool-Kit?
  5. New teams needing Planning Poker and User Story cards? Our #BecomingAgile Product Series might have just the thing.
  6. Do you need to prep for the PMI-ACP exam but don’t have the time to attend a 3 day class?
  7. Need to brush up on your Agile vocab? Check out our Agile Glossary.
  8. Are you aware all of our #BecomingAgile Webinars are archived so you can view them again?
  9. Is your organization clear on the fact Agile is more than Scrum? Kanban is great too!
  10. Do you struggle with keeping momentum for change? Agile is about embracing an attitude of continuous improvement. There is a Less Painful Way.
  11. Have you addressed the discipline of Quality Assurance and embedded as much testing as possible within each iteration? An Agile Testing class might be for you.
  12. Is technical excellence eluding you? The ‘process’ aspects of Agile will only get you so far. Continuous Integration is the key.
  13. Are you worried about failure? Keep your eye out for The Failed Agile Adoption Pattern.
  14. Could you be missing out on special promo codes and Agile tips? Be sure to follow us on twitter – @davisbase and our hashtag #BecomingAgile.
  15. Do you have specific questions about how we can help you in your Agile journey?

We hope to see you at some of our upcoming events and look forward to assisting you, and your organization, with your Agile journey. Happy New Year!

The Art of Servant Leadership

blogimage - Servant_LeadershipIt’s easy for people to throw around the term “servant leader,” but its another thing to actually be a servant leader. Just as our Davisbase Consulting trainers and coaches tell clients — learning Agile concepts is relatively easy, but putting them into practice is much harder. Similar to the way Agile is a philosophy, and mindset, for how teams can deliver value, servant leadership is a philosophy towards leadership. By executing the practices commonly exhibited by true servant leaders, doesn’t necessarily make you one.

During our December #BecomingAgile webinar, Leslie Morse will guide us through values, principles, and practices of servant leadership as well as provide webinar participants with a quick assessment that can help you decide where you are on your journey to becoming a true servant leader.

Register now and we hope to see you there!

Proactive Stakeholder Engagement

It seems as if many of my recent client conversations have circled around a singular topic, Business Readiness. The more we’re practicing Agile concepts (Scrum specifically), the more it becomes apparent that given the perfect conditions, adopting Agile is pretty easy. The challenge is that we’re never given the perfect conditions. As a result, much of the coaching and training I do focuses very little on Agile or Scrum. More often it focuses on the other organization complexities that exist within companies today. So today, I’m going to make a pretty bold statement, but I’m doing it in order to make a point.

Teaching a single team Agile concepts is easy, but preventing them from delivering rubbish is hard.

It’s true. Given the perfect conditions, you can teach a single team (or maybe even 3-4 teams) enough to do the basics of Agile sufficiently well in 60 – 90 days. We are seeing that basic team instruction is becoming somewhat of a commodity, however, just adopting Agile practices and mastering Scrum won’t get the benefits that Agile has to offer.

In fact, getting the true benefits of Agile starts with the business, and the idea of business readiness. Are Product Owners even asking for the right thing? Have they aligned all their stakeholder to ensure that there is consensus and understanding in order to prevent unnecessary rework that could have been avoided by a single conversation?

Here are my three suggestions for better business readiness:

  1. Stop Running, Slow Down!
    Just because the project seems like a good idea, doesn’t mean it is one. Too many projects get approved and put through the pipeline and organizations are overburdened with too much Work in Progress (WIP).
  2. Clean the Junk Drawer
    Often times the scope of new workstreams is weighted down with leftovers from previous projects, nagging production defects, enhancements, and new functionality. When defining scope it is critical to focus on the smallest set of features that, if deployed, would add value for end-users.
  3. Define a Stakeholder Engagement Strategy
    Who are the influencers on the effort, and what is the right frequency to engage them to ensure the right level of proactive input? The engagement of these individuals cannot be left to chance. They’re often busy individuals and it takes weeks to get on their calendars. That wait time is a bottleneck for teams and causes waste within the value stream.

The first two in that list are not in scope for today’s exploration, but I do want to offer a few suggestions on #3. A stakeholder engagement strategy is a key element of any successful Product Owner’s game plan. Its accomplished by completing just a few simple steps.

  • Step 1: Analyze Stakeholders
    Who are they, and how close are they to the work?
  • Step 2: Define the Cadence
    How often should you meet?
  • Step 3: Follow-Through
    Keep the discipline for the sessions.




Step 1: Analyze Stakeholders
Who are they, and how close are they to the work?

More often than not a three-tier classification model is sufficient. It all starts with the Product Owner though. The single source of truth to the Agile Team(s). They act as the funnel, aggregating input from all stakeholders in order to ensure there is a single voice guiding the “what” the team works on. Keep in mind, in your organization it may not be realistic for the PO to bear all this burden. Very often it works best to pair a Business Analyst with the PO to help with eliciting information, analyzing results, and aligning the stakeholder group.

  • Advisors
    These are the individuals closest to the work. Apply the same rule-of-thumb used for sizing Agile teams. 7 +/- 2 should be enough to compose a committee of Advisors. In practice, I often see this group include the PO’s direct leadership, someone from user experience, and a representative from architecture (or a tech lead). Other groups to consider would be training and operations support.  Product Owners should rely on Advisors to help validate priority, high-level acceptance criteria, and completeness of functionality within the backlog.
  • Supporters
    These individuals are often 2-3 degrees of separation from the work. They may be of a slightly higher leadership level, peers of the Product Owner’s direct leadership, or come from groups within the organization that are more indirectly impacted by the work the team is doing.
  • Sponsors
    Higher levels of leadership often make up this level of stakeholder. They are engaged in order to guide the overall direction of the work the PO is doing, and are very useful in resolving conflicts of opinion among other stakeholders within the group.

When analyzing stakeholders, don’t forget that all types of stakeholders should be considered. Actual end-users, business groups, leaders, and technology specialists should all be evaluated when determining stakeholder classification.

Step 2: Define the Cadence
How often should you meet?

There is no single-right answer to the idea of cadence. The figure in this post outlines an option for you. You can see it prescribes a weekly meeting time. The time each week is the same. The only variable is WHO. Based on the stakeholder map across the three groupings, a different “team” gets together. You may decide a cadence based on meetings every other week are good enough, it’s truly up to you.

In addition to cadence, its also important to determine the focus. Try not to dwell on what the team has already delivered, these sessions are intended to capture proactive input on what the team has coming up in the future. If you’ve watched the recording of the Strategies for Grooming Your Backlog webinar, then you’ve got the idea that this focus is likely 3-4 iterations ahead of where the team is currently working.

Step 3: Follow-Through
Keep the discipline for the sessions.

There is always something to discuss. Don’t cancel the sessions willy-nilly. Keep the habit of the meetings to ensure participation and engagement of the stakeholders. It may be slow to start, but over time you’ll find this invaluable, and the stakeholders will be delighted with their input is manifested in the product demos at the end of each sprint.

I hope this was useful, it’s a passion area of mine, and please share your success stories on these types of stakeholder engagement patterns!

A Summary from BBC 2014

I had the pleasure of conducting a 3-hour pre-conference tutorial at the Building Business Capability (BBC) conference earlier this week. It was truly a lovely time. The team there was welcoming, and if you’ve never attended an event at The Diplomat in Ft. Lauderdale, FL – GO! Its a wonderful facility.

Sadly, my time at the event was limited, and I did not get a chance to connect with many folks in attendance. If you missed out on my session, Advanced User Stories, then here’s a re-cap.

The Materials:

In the beginning… 
There was a room full of business analysts grouped into 7 groups (6-8 people each). There were also a lot of blank posters on the wall.

start 1start 2

Then the magic happened…
I lectured some, the groups collaborated, questions were asked & answered, the posters were filled.

general 6 general 7 general 1 general 2 general 3 general 4 general 5


The results were captured…

Lifecycle of a User Story

lifecycle 1 lifecycle 2 lifecycle 3  lifecycle 4 lifecycle 5 lifecycle 6 lifecycle 7


Techniques for Supporting & Elaborating User Stories

techniques 1 techniques 2 techniques 3 techniques 4 techniques 5 techniques 6 techniques 7


Practicing Story Elaboration – Use Cases

use case 1 use case 2


Practicing Story Elaboration – Specifications by Example

example 1 example 3


Practicing Story Elaboration – Given-When-Then


And then we reflected on how to improve…
What should we Start, Stop & Continue.

Start Stop Continue
  •  Bringing Value First
  • Leverage User Stories to define deliverables for Knowledge Management
  • Try Specifications by Example
  • Get comfortable with “Just Enough”
  • Trying to groom stories just a little every day, have longer workshops 1-2 times per sprint
  • Trying to get the perfect story on the first try
  • Bearing all the burden for refining stories
  • Using Story Mapping
  • Detailing Acceptance Criteria

Additional References:

Useful Resources & Posts from Davisbase:

Wondering what participant’s said about the session?

Great workshop, it was really interactive and provided good insights into how to create user stories and what additional information is required. User stories are not enough.
– Darcea Klein, BSA @ Alberta Pensions Services


A Valuable Insight: We need to enhance our User Story Lifecycle to ensure readiness.
– Lisa Cornelius, Manager – Product Development @ Jewelry Television


A Valuable Insight: We are new to SAFe / Agile. This helped me understand that some of our insanity is just that, insanity.
– Angela Thomas, Manager – BA Team @ The Kroger Co.


Take this workshop and walk away with real, tangible Agile techniques.
– Sandra Jones, Sr. Business Systems Analyst @ K-love & Air 1 Radio

The PMO Minefield


Photo: Tony Wheeler/Getty

First, before anyone starts firing off angry emails, let me state a few clarifying points:

  • I am a card carrying member of PMI
  • I studied the PMBOK extensively as part of my MBA program
  • I do not hate Project Management(!!!)

With that out of the way, let me further elaborate by stating that the notion of a PMO is extremely dangerous. Add an Agile culture and you have a stage set to go nuclear.

Agile and SCRUM do not eliminate the need for Project Management.

Agile and SCRUM do not eliminate the need for a PMO.

We just need to change how we look at these functions.

So why a minefield?

Lets be honest. How many of you really know what the PMO does? How many of you know what the PMO should do?

For those of you who said “yes Adam, I KNOW what a PMO is supposed to do.. it ensures value”

Ok – great! Can you define value?

BOOM! Mine detonated.

Provide a home for Project Managers. Are your PMs a part of their project teams, or apart from their project teams?

BOOM! Theres another.

Define and support a methodology. Do you and your end users define your process, or do your tools?

BOOM! Another.

YES.. the PMO was stood up to add value.. and to serve as a “home” for the project managers.. and to reinforce methodology. But please keep one point in mind: if you are in the PMO, you are evaluated based on how well YOUR process is adopted. It is in your best interest to dig your heels in, dictate process, and do things that are in the best interest of the PMO.

How Agile is that?

Lets shift that paradigm!

Agile teams are all about improving the process. Discovering new efficiencies. If, as a PMO, we change our mindset from “do as I say” to “lets talk about how we can make our lives better”, folks will likely stop running every time they see the PMO police coming.

So what does that mean? Here is a very concise list of things that a PMO purist can change in their doctrine to survive and THRIVE in an Agile culture.

1. RELAX!(!!!) It isn’t that serious. We understand that you want to do a great job, and we want to support you, just tone it down a smidge.

2. Resist the urge to dictate, and listen to where the pain points are. By listen, I mean REALLY LISTEN.

3. Become an expert in the manifesto and principals. Embody them. Sign the document.

4. Learn expert skills in teaching and coaching. Remember the foundation of the house of lean – leaders are not managers, they are teachers.

5. Understand what value is. I mean REALLY understand it. How is the PMO contributing to the bottom line? PMO purists love EVM, figure out how to apply it to your own world!

The bottom line is this: We do not want to run from the PMO. We do not want to resist the PMO. In fact, we need the support of the PMO!

Please help us, to help you, help us.

Scope & Expectations Management in Agile

Definition of DoneOne of the biggest complaints and frustrations from new Agile practitioners is, “We don’t know when we’re done!” That’s not an uncommon situation to be in if the organization falls on the side of purely self-organization. However, transparency and higher levels of customer satisfaction are two key benefits of adopting Agile practices. Achieving these benefits takes a high level of discipline and the right patterns for collaboration and engagement.

Join us on Thursday, November 6th at 12:00 PM ET for this month’s #BecomingAgile Webinar, where one of our Managing Directors, Leslie Morse, will walk us through 4 key practices that will help ensure you’re able to effectively manage stakeholder expectations and properly communicate about what teams can deliver when.  These are:

  1. Define Scope leveraging KANO analysis
  2. Project delivery dates using a Release Burn-Up Chart
  3. Track incremental delivery with Feature Burn-Up Charts
  4. Analyze Trade-Offs with a Tactile Release Plan

Sign up now!

Design Thinking (Part Two)

In our last blog post Design Thinking Part 1, we discussed the overarching stages of the Design Thinking process based on the book, Designing for Growth by Jeanne Liedtka and Tim Ogilvie. Those phases are, what is, what if, what wows, and what works? Now you’ll learn the 15 steps to guide you through the Design Thinking process.

Before you start

1. Identify an opportunity
Design Thinking works well for two situations in particular. First, finding solutions to problems that have many unknowns. And secondly, coming up with innovations and areas of growth in your organization.

2. Scope your project
Start with a basic statement of the area of opportunity, then write out ways that scope can be broadened, and finally, go the other direction to see how that scope can be narrowed. This is an exercise that will help you start to see the opportunity in a new light.

3. Draft a design brief
In Agile we call this our Project Charter. It’s a simple one page brief to outline the area of opportunity, any key stakeholders, scope, constraints, expected outcomes, and success metrics.

4. Make your plans
Here you will decide the basics of the process. What is the timeframe, who will be involved on the team, and/or will it be a solo effort?

What is?

5. Do your research
In this step, you will gather insights about the state of your current reality. This research can be done in any number of ways. Interviews with stakeholders and/or customers, direct observation, secondary research (about industry norms, for example), value chain mapping, creating user personas, and journey mapping are all options. Just remember that this research gathering needs to be human centered, so aim to be as empathetic as possible.

6. Identify insights
Once you’ve gathered all this research, put it into a format for your team and even possibly your stakeholders to see. One common way is to make low cost posters at your nearby FedEx Office. Then you will hang the posters in a room, and give everyone a chance to walk around and capture insights on post-it notes. After about 30 minutes have them put their insights into clusters. These will be referenced later in the brainstorming step.

7. Establish design criteria
Now that you’ve got a solid idea of the opportunity in front of you, answer the question, “the ideal solution would ____.” In this step we aren’t solving the problem, but rather making clear the end result we are looking for.

What if?

8. Brainstorm ideas
We’ve finally made it to the solution generating phase. In this step we want to explore any and every idea to give ourselves a very large base to choose from. One great brainstorming process is very similar to a retrospective technique we use in Agile. Give everyone a post-it note pad, and give them 3 minutes to quietly and individually come up with as many ideas as they can. After the 3 minutes they will share their ideas with the group. Following that, they will get a second round of 3 minutes to come up with more ideas individually.

9. Develop concepts
Put all the post-it notes from the brainstorming session on a large board or wall where they are all visible. This next phase is where we start to build concepts. These concepts can be based on multiple ideas that came out of brainstorming, or even themes that the team struck upon.

10. Create some napkin pitches
In our Davisbase Agile training courses, we teach this exercise to our classes, and call this practice an Elevator Pitch. It’s a short pitch to convince someone of the basics of the opportunity, and the value proposition attached. Once you have a few concepts developed from the last stage, practice making some napkin pitches from them. Teams can develop these together, or as individuals and then pitch them to the other members of their team.

What wows?

11. Surface key assumptions
By this point in the process, the team’s energy is high, and they are ready to take these ideas to market. Before we do that, we need to burst their bubble just a bit, and surface the key assumptions that we are making in our concepts. What are the assumptions we are making, that if proven false, would prohibit our concept from being successful?

12. Make prototypes
Start to build prototypes of your concepts that you can begin to interact with and show to your stakeholders and/or customers. These can be in any variety of formats. They could be actual 3D objects. They could also be something 2D like a flowchart, storyboard, video, or even a drawing.

What works?

13. Get feedback from stakeholders
In this step we will introduce our prototypes to our stakeholders and/or customers. There are a few key ground rules to keep in mind. First, no selling. You shouldn’t have to convince your audience that these are good ideas. Second, offer only a small number of choices. Having 2-3 options available will help you to see which one your audience gravitates to. Lastly, aim to have a diverse group in your audience. This will help to ensure that there aren’t key assumptions that you’re missing, or that are false.

14. Run your learning launches
Now that you’ve developed your prototypes and have sign-off from your stakeholders, design the framework around how you will test these concepts, and test them! In this phase, it is critical to be willing to fail. Forcing a “solution” on your customer that isn’t actually solving a problem won’t benefit you or your customer.

15. Design the on-ramp
This last step is all about putting your successful prototype into place. This is the phase where we will introduce the new feature to our Agile teams to build. Additionally, ask yourself key questions like, “What will cause our customer to begin to use this product?” and “How will we entice customers to repeat their business?”

Now you’ve learned the four overarching principles of the Design Thinking process (what is, what if, what wows, and what works), and you’ve got 15 actionable steps to put each of these phases into place. Contact us to help you through this process, and also find ways it can enrich your existing Agile process.