Active Architecture – User Stories for Architecture

I had previously blogged about how I felt that “System User Stories” were required and filled an important gap. I now believe that extending User Stories to create these System User Stories is not the best solution.

I still believe that there is a gap in Agile techniques that needs to be addressed for certain types of applications. For simple CRUD applications it is very possible that you will not require these additional techniques. This discussion is meant to address those non-trivial CRUD applications. I think my error was in trying to extend the brilliant User Story concept to cover System Stories. I now see that it was a bit of a forced fit. What I would propose instead is something I refer to as Active Architecture documentation.

The argument for Active Architecture

Too frequently in Agile, the focus on Requirements is only on User Stories. Sometimes the focus is on User Stories and Technical Tasks, but not on any architecture or holistic system design requirements. While this may be acceptable for Web applications that are simple, trivial, and primarily event-driven, it certainly does not suffice for applications that may have complex back-end components such as:

• Portfolio Rebalancing Engines
• Payroll Engines
• Network Optimization
• Scheduling or Matching Engines
• Really any application that has an engine. 🙂

Unfortunately, the amount of Architectural and Design Documentation has been greatly reduced by Agile due to the enormity of it and the waste. I agree 100% that there is waste, but I would suggest that the correct response was to create a new, leaner type of Architecture document. Instead of the traditional voluminous passive Architecture document, I recommend a new Active Architecture document that is composed of Component Conversations as illustrated below:

The issue with the traditional architecture documents are that they defined what the architecture was in a passive and distant way. Somewhat like a road map. What I am proposing is to define the architecture in an active way. Rather than just defining the map of roads, the documentation needs to define how the routes will be driven and in that active way, describe the road map. The traditional way of architecture documentation was too far removed from the actual act of system use to be relevant and effective. Architecture documents need to define what actions the architecture support, just like User stories did for user functions.

User stories capture interactions between the user and the system efficiently, and technical tasks capture lower level tasks that the system is required to do. But where in the Lean documentation do we define at a High level the interactions between system components?

The types of Agile Requirements I recommend are:

1. User Stories – Stories of how the User interacts with the application or manual processes
2. Component Conversations – Conversations between components of the application
3. Technical Tasks – Technical tasks that the applications needs to perform within a component.

Creating these component conversations and thinking them through for the entire system will ensure the following:

• That our User Stories are consistent in how functionality is handled across components
• That our User Stories do not create an undue amount of rework when an original story is encountered in a later iteration
  • Ensures that the entire solution has been thought through at a high level
  • Reduces the chance that a story will be discovered late that will require earlier stories to be revisited
• That our technical tasks are implemented consistently across components
• They will define the complex back-end high level requirements that would be inefficient and possibly inconsistent to define on a story by story basis
• They will define complex back-end high level requirements that may not be covered easily by user stories
• Components conversations can be reviewed to ensure we have all the system functionality covered and there are no gaps.
  • Ideally in a graphical way

These Component Conversations define the Active Architecture of the solution. One possible format of the Components Conversations are: (and you can customize to fit your particular requirement)

[#][Component A] does [primary action].[object].[additional action] by [Action].[Component B] when [event]

Summary

I’ve used these component conversations on my current project and they have greatly improved the understanding for both myself and team members. It is crucial that these component conversations should not be very involved and take a long time. I time box of 1-2 days should be sufficient to ensure a consistent understanding of the system exists. The component conversations can then be modified and changed as we proceed through iterations. The focus should be on Lean and what is enough to provide the required value.

The concept has provided great value for my current project.

Advertisement

User Story Points and User Story Hours

This Blog post may be somewhat controversial, but I really think it provides a viewpoint that I don’t normally see represented. I urge you to read the entire post before jumping to conclusions. Here goes:

The Politics

I’ve read many a good post on estimating Agile projects, but I must admit the discussion about estimating via User Story Points versus User Story Hours seems to suffer from partisan politics. If someone believes in User Story Points, they paint the only alternative as a bleak Orwellian future of accounting for time in 5 minutes increments and shock therapy for the failure of missing estimates. They usually also assume that if you don’t buy in fully to User Story Points, you also don’t believe in Agile in general, Planning Poker, and are an avid fan of Waterfall. Nothing could be further from the truth.

What I would like to have is a bi-partisan discussion of the pros and cons of different estimating approaches.

Disclaimer

Before I start I would like to state that I believe that User Stories, Planning Poker and Story Point Estimating should be done on each and every project. What I am discussing and proposing here is not about not doing Planning Poker and Story Point Estimating, but rather discussing whether the estimating should stop there or continue with other additional methods.

The Continuum

There is a continuum of approaches for estimating. This is illustrated in the diagram below:

When discussing the pros and cons of Story Point Estimating, we are usually limiting our discussions to just the two extremes. I would like to propose a hybrid approach as well.

Agile	The Agile approach is the one that is most commonly proposed in the Agile literature. This approach proposes estimating by User Story Points and these estimates are typically generated in a Planning Poker Session(s). The Planning is then done by planning the Iterations based on the number of User Stories and their associated points.Success is then usually judged by being able to achieve a stable User Story Point Velocity from which to execute the remainder of the project in iterations. This Velocity is used in an iterative and ongoing basis to refine the plan for subsequent iterations based on past results.
Traditional	The Traditional approach is defined by creating very detailed task level estimates in hours. These estimates may be done by the team, but usually are done without the team or with a subset of the team. These estimates are usually created without the input of developers. The Planning is then done by creating a Work Breakdown Structure. The Work Breakdown Structure is then applied over a timeline or schedule to create the fully detailed Project Plan.Success is usually judged by the accuracy of the task estimates which will then translate into meeting the estimated schedule generated from the Work Breakdown Structure.
Hybrid	The Hybrid approach proposes estimating by User Story Points and these estimates are typically generated in a Planning Poker Session(s). The Planning is then done by planning the Iterations based on the number of User Stories and their associated hours. The User Story Hours are created by converting the User Story Points into User Story Hours.Success is then usually judged by being able to achieve a stable User Story Point and Hour Velocity from which to execute the remainder of the project in iterations. The User Story Point Velocity is used in an iterative and ongoing basis to refine the plan for subsequent iterations based on past results. User Story Hours are provided to the owners of User Stories so they know what the original estimates of the User Stories were.

What are the pro and cons of each approach?

Well we all know the pitfalls of the Traditional approach, so let’s not even discuss that approach. 🙂 But why is the Hybrid approach compelling when compared to the Agile Approach? In fact, the Agile and Hybrid approach are very similar except for the fact that the planning is done in User Story Hours and the velocity is measured in User Story Points. In addition, User Story Hours are then provided to the owner of each User Story to provide a frame of reference as to the initial estimate. Let’s look at the pro and cons of Agile estimating concepts and how User Story Hours can help mitigate the cons.

Concept	Pros	Cons	How do User Story Hours help?
User Story Points	Minimizes the human element of having duration or hour perceptions influence estimates.	May force the ‘slotting’ stories into non-ideal slots. (i.e. It is a 30, but all I have are 20 and 40 slots)	Provides a second review once you have converted to User Story Hours to ensure the estimates are consistent and make sense.
Relative estimating	Establish standard grouping and increase accuracy by relative estimating. Also leverages human ability to excel at relative estimating.	Creates single point of failure. Base line estimate which all other estimates are relative to can create a ripple effect of estimate inaccuracy. This may take multiple iterations to correct.	Remove single point of failure with reality check. Second review will ensure estimated hours make sense.
Planning poker	Increases team buy in, shares estimating expertise and promotes team growth, helps to refine solution understanding, and increase estimating accuracy.	None.	Not Applicable. This concept is used in both the Agile and Hybrid approaches.
Velocity and Burn down	Validate estimates and plan at a macro level. Not at an individual, user story or task level	None.	Not Applicable. This concept is used in both the Agile and Hybrid approaches.

Perhaps the most important benefits of User Story Hours are that they allow for the derivation of a project budget and schedule. One of my biggest challenges with the User Story Points approach is the concept that it will take two or three iterations to determine your velocity and then you can inform your client when you can complete the project and how much it will cost. Very few projects I have been a part of can get a blank cheque for two or three iterations and then confirm if the project is feasible and has business value. User Story Hours still allows you to have that check at the end of each iteration AND also create an estimate at the start to ensure the budget and schedule satisfy the project’s business case. Although the estimate still is not ideal, it is better than not having an estimate at all.

And please stop saying that we shouldn’t estimate at all. Just stop, you are hurting innocent people. 🙂

I believe it is disingenuous to propose something as a principle that you know applies to a very small minority of projects. We need more ideas to bridge this reality gap of executing project in an Agile way and requiring project estimates up front to validate a business case.

The Data

I’ve read many posting on the perils of converting User Story Points to User Stories Hours and how a common conversion factor may not be feasible due to the difference confidence factors for each User Story size. I believe this is a red herring. The postings discuss how the conversion factor will be more of less accurate for different stories of different sizes. I couldn’t agree more. And it doesn’t matter.

All we are concerned with is if the conversion factor holds on average for the entire project. I’m not expecting it or requiring it to apply to individual estimates. I’m not holding individuals accountable for User Story Hours for each User Story, as I know these items will follow a Normal Distribution. (In fact the studies I have seen have prototypical Standard Distributions. An excellent post by Mike Treadway illustrating this can be found here: http://the-tread-way.blogspot.com/2011/04/how-many-hours-are-in-story-point.html)

Let’s look at the data Mike Treadway compiled:

User Story Points	Average Estimated Hours	Average Actual Hours
1	8	6
2	5.5	4.5
3	5.67	5.33
5	5.4	5.8
8	4.75	4.375
Overall Average	5.864	5.201

In this example,converting to and using Estimated Story Point Hours results in an 11.3% difference between estimates and actuals. This is very much in line with the 10-15% project contingency commonly quoted. So it appears that this method is not introducing additional inaccuracy. Please note I am not saying you don’t continue to manage in an agile way monitoring velocity and adapting as you execute. But this would allow for a checkpoint before you start your project that your schedule and budget are feasible. Without this I fear we may give Agile a bad reputation by starting projects that should not have even been started because they did not satisfy the business case.

I also realize that the User Story Hour Velocity will change from iteration to iteration. This factor does not take away from the value of converting to User Story Hours. Trying to use this argument is another partisan point where the argument implies we are going to use the conversion factor to manage in a traditional manner. We are not. We are using the User Story Hours to only plan and manage in an Agile manner. The important factor for both User Story Points and User Story Hours is that we manage by Iterations and at a higher level of abstraction so the individual deviations in estimates are expected and do not matter.

So given the fact that we need to convert to User Story Hours to validate the budget and schedule before we start, why wouldn’t we use them in addition to User Story Points as we manage iterations? I can’t think of any reason but I’d like to hear opposing viewpoints.

Two Final Points

1)      The conversion to User Story Hours is done by the team and changes are only made by the team. There is no Project Management influence to modify the hours. This is absolutely critical.

2)      I’ve heard the comment that providing estimates in hours will affect the developers doing the User Stories and they may alter their behaviour and deliverables. I believe User Story Hours is merely another piece of information that developers should have when undertaking a story. I think having the User Story Hours will let the developer provide feedback immediately if the estimate is incorrect and allow for immediate adaptation. Otherwise we may only find out that our velocity is an issue a week into an iteration. Why wouldn’t we want to know if there are concerns immediately? Developers I have polled have stated they would like to know the initial hour estimate to be able to possibly raise a red flag early. They stated User Story Points do not allow this to be done as easily.

I’d like to hear why people are averse to using User Story Hours and communicating User Story Hours to developers. I’m sure there are some factors I have not discussed.

I think the benefits realized by developers knowing the initial estimates outweigh the dangers of the developers working to those estimates. A true Agile environment and team can allow User Story Hours to be used for good rather than evil.

Please let me know if you find this interesting and whether you would like to see a subsequent post on how you can convert from User Story Points to User Story Hours.

Agile Experience Reports – The Agile Dozen

My main purpose for this BLOG was to try and share some personal Agile Experience Reports and get discussions going with others on what worked and what didn’t work. My first challenge was to create a framework where some sense could be made of my personal project results.

When I compiled the list of Agile practices that I feel are important to projects, I was worried about how any patterns could emerge with that many factors. And I was right. I had compiled a list of 42 characteristics and practices that covered the Project Team, Project Planning, Execution, Requirement Gathering, and Development activities on the project.

What I did next was look at those 42 characteristics and practices and whittle it down to 5-10 Agile practices that I believe are really key to project success. Unfortunately, I could not get it below 12. So I was stuck with the Agile Dozen.

Next was the step to validate that those practices were indeed a true indication of project success. And through the projects reviewed so far, they have held.

For my upcoming Agile Experience Reports I’ll share how well we followed all 42 characteristics and practices on a rating scale of 1-5. But I want to caution that I am not viewing this rating as:

• An Agile scorecard
• An Agile Maturity
• An Agile report card

I think those constructs cause teams to focus on the wrong things. Namely, getting a good grade rather than project success, client success, and continuous improvement. I created this framework to help myself understand what practices really contributed most to project and client success and help me to improve and focus on the right practices.

In the next BLOG post I’ll discuss in details the Agile Dozen and my rationale for including them. For now, here is the list of the Agile Dozen..

• Team Experience (Technical & Domain)
• Developer to Designer Ratio
• Embedded Engaged Client
• Team Continuity
• Team Estimating
• Automated Tests
• Team meeting estimates
• Daily stand ups
• Retrospectives
• Iterative Delivery
• Epics, User Stories and Product Backlog
• Continuous Integration

Then I’ll provide some context on where these characteristics existed and practices actually worked on projects and share lessons learned.

I hope you will find this interesting. I tried to find information like this when I was starting out and I could not find it very easily.

A System User Story Holy War? On a Saturday night? :)

I’ve struggled for a while with the concept of System User Stories. I know about the debate and argument that about only User Stories should be used to measure progress. And I agree 100%. I am not proposing that these System User Stories would be used to manage the project and measure progress, but that they would be used to validate and confirm the system design and completeness of User Stories. In essence, they don’t remove the need for User Stories but are an additional activity and deliverable. I also feel they are an invaluable light weight model that documents System behaviour. I feel the lack of Application or System definition between User Stories and Test Cases and Code is just too broad of a gap. There is room for a light weight model to fill that gap and ensure our solution has a high level of completeness and cohesion.

In my definition, these System User Stories are stories that define how the system components are interacting with each other at a high level. They have been attractive for me for primarily three purposes:

1. To examine the full behaviour of the Application/System to confirm that the design and concept is full fleshed-out and complete.
2. To create a light-weight model to capture the Application/System behaviour for communication through out the team.
3. To confirm that we have the appropriate User Stories and tests across the entire Application/System.

One thing that has always troubled me about User Stories is that unless there an end-to-end light weight model of the System, we may have the system architecture and design affected when User Stories are worked on in later iterations if the functionality starts to diverge from previous understanding. Having a light weight model of System User Stories that we can then validate Traditional User Stories again greatly reduces this risk and highlights any areas not covered. I think the System User Stories have more value for complex systems. I am currently working on a very complex system, and I feel System User Stories were essential to ensure our design and scope was complete, correct, and compelling. Since the project is somewhat R&D we also lack a Traditional Product Owner so this task falls on the project team. System User Stories helps us to clarify this concept.

So given the fact that I think they are required, what format do they take?

What I have found to work is that they should be in total no more than 2-3 pages in total. Any more than that and you are going too deep and not just confirming overall design and consistency. You are actually doing requirement definition.

I also like the User Story type of format. It is complete and concise. The format I have used is:

As an [Domain Specific Language Component] I will [do a Domain Specific Language Action] when [Event] using [Domain Specific Language Components or System Components] 

The Domain Specific Language Components and Actions can be anything from true DSL Components or Actions to just the abstraction to the high level components used in the System or Application. It definitely should not be at a low-level. I also have broken these System User Stories into major features just for easy categorization and organization.

And then finally I renamed these System User Stories as System Grammar. I did this to shy away from the System User Story holy way and also to reflect that these rules truly are the grammar that the system uses to build its language of functionality.

System Grammar. I think there is a place for it.

User Story Mapping – Oscar for best presentation ever!

I now know why a colleague of mine at Protegra has been raving about this User Story Mapping presentation from Jeff Patton. I have read up on the concepts but until now did not fully review the presentation.

Simply put, this is the best presentation I have ever seen both in style and content. Awesome.

http://www.agileproductdesign.com/presentations/user_story_mapping/index.html