Scrum as It Relates To Billing

I have found that the term "feature" in the context of scrum can be a bad word among purest. Many software engineers that practice scrum use words such as user story, task, points, actor, sprint, iteration, chicken, pig, etc. However, if you are software engineer that has had the pleasure of working directly with your customers, you have found that they do not necessarily know what you are talking about and they probably should not need to know. Therefore, the term "feature" rears its ugly head in order to bridge the gap between your jargon and the language with which they are already familiar. I say ugly because many purest view the term "feature" as a throw-back to the waterfall model. But, I claim that a feature is really the high-level manifestation of a collection of user stories.

For example, suppose the customer considers the user login as a feature while the following user stories make up the functionality of that feature from the software engineer's point of view:

• As an anonymous user, I must login to the system in order to be granted the correct access rights within the system.
• As an authenticated user, I want to be able to log off the system because my computer is shared with other users.

When speaking directly to my customers, I generally map the user stories to "features" in my head or on paper for their benefit. However, it becomes easy to lose track of this mapping in more complex scenarios especially when dealing with multiple customers at one time. Regardless, all of my customers want to be billed based on satisfactory delivery of "features" and not user stories (if you have had a different experience, please let me know your secret). It has been my wish for several years to work through a solution that would bridge the gap between the impression that the customer has of the product in terms of billing with the impression that the software engineers have in terms of creating the product.

This solution is to be included in ScrumTime 1.0 as a new level in the existing work item structure. ScrumTime 1.0 will have support for features in the form of children of the product work item level. For example:

• Product - Personal Inventory Tracker
• Feature - User Login
• Story - As an anonymous user, I must login ...
• Task - Create the login div container

Also, the feature may be assigned to a release but not to a sprint. I consider "release" to be another one of those terms that is important to the customer but not important to the software engineer. For example, a customer may say that they want a specific feature to be in a specific release. From the software engineer's point of view, the set of user stories that make up that feature must be implemented by the end of a specific sprint. In fact, it may take two or more sprints to complete all of the stories that make up the feature. This sort of visibility must be available in ScrumTime 1.0 or I will have no use for it in my day-to-day work. Yes, I plan to use ScrumTime 1.0 day-to-day.

One of the main benefits that I look forward to is that task work hours will now bubble up to the level of features providing a actual billable hours for the customer. In the past I have had to rely on my own custom spreadsheets to keep track of the mapping and the correct hours to charge. Based on my experience, I will need the ability to credit hours at the feature level in the event that a task takes more time than should be billed.

 

 

This topic leads to an entirely new aspect of the ScrumTime road map known as the planned customer view. The idea is to allow your customers to be able to login to your hosted ScrumTime in order to submit new features, approve cost estimates per feature, and participate in the product discussions that require their feedback. Using the terms "feature" and "release" make this sort of customer self-service more feasible and attainable.

 

 

In summary, I plan to add a new level into the existing ScrumTime work item hierarchy known as the feature level. This will provide a bridge between the customer point-of-view and the software engineer point-of-view. The benefit is that the tool will be able to track more of the customer feedback loop that is vital to successful software development projects.