Posts Tagged “features”

I’ve never been a huge fan of the as-a-user approach to user story naming. It’s not that I never use it. In fact, I even used it once last week:

As a user, I want an edit button next to the issue icon in the search results so that I don’t have to click all over hell in order to edit something in Jira.

See. A well formed user story name following the as-a-user convention. And it really gets the point across.

I’ve never been a fan of consistently using this approach, but I’ve always had a problem putting a finger on exactly why. It is a pretty good approach. And its hard to argue against consistency. Seriously, it is.

Then, last week, I read Artem Marchenko’s post Why I don’t use standard user story format that much and things suddenly clicked in place.

In his post, Artem argues that standards for standards sake aren’t useful and that the as-a-user approach is not a highly-tuned tool to train the team to focus on the end user (if they don’t buy into the idea this won’t help). He does specifically call out one benefit he sees from the as-a-user approach, and that is when similar functionality within the software may have different stories to benefit different users.

And that’s when it crystallized for me.

We should name user stories (or features, or any other deliverable) based on the conversations we want to have about them. This way, we can frame the correct context of our discussions around prioritization and requirements.

If we have a system with many roles and one product owner (or customer), the as-a-user approach may make a lot of sense. However, if we have a group of stakeholders who prioritize the stories, it may make more sense to establish a pattern that highlights the benefit of each story. A pattern, for example, that starts with the benefit to be derived from the story:

  • Reduce tech time spent on maintenance activities by building an ad hoc query browser for the operations group
  • Increase conversion by removing the optional fields from the account creation form

One can argue whether each story will actually achieve its stated goal, but isn’t that a huge part of prioritizing stories and defining requirements?

In the absence of any other need to frame the conversation, I use Story Titles, which must be short and specific. For example:

  • Schedule Group Appointments
  • Self-Service Pixel Management
  • Workstream Hierarchy Tab on Sprints Page

You don’t get all the details, but there’s enough information to clearly distinguish one story from the other. The naming approach behind Story Titles has two goals: (1) to communicate a clear sense of what is being done, and (2) to be short enough that the name is memorable and used consistently. This approach is essential for activities like the Feature Building Workshop.

Just as one-size-fits-all fits no one well, no one approach to naming user stories is always right. In order to determine the best story naming convention for a specific situation, you must know how you want to frame the conversation.

Comments No Comments »

Once you realize that you’ve put yourself in a deep hole, please please please stop digging.

In the past few years I’ve been involved or drug into countless discussions about teams that have incurred technical debt. And I must admit to initiating more than a few of these discussion myself. The funny thing is that the theme of these discussion is almost always the same: “How do we get the business and upper management to understand that this system really will implode if we don’t start prioritizing some of this debt.”

I cannot, right now, recall a single time when the conversation’s theme was: “How do we stop digging?” I admit, that must have occurred … at least once … but I cannot recall it right now.

Yes, there are real business decisions that cause us to incur technical debt. Technical debt often results from a prioritization ethos that focuses on low-estimate patches and sidelines large or even mid-sized features. It can also result from a focus on revenue generation that entirely ignores cost savings. For example, imposing routine manual activities that may be better handled by simple ad-hoc reporting systems or crud maintenance screens.

This said, I’ve never seen a technical debt backlog that did not also include–or was even overweight with:

  1. Gaping holes in test coverage,
  2. Swaths of documentation-free code,
  3. Opaque data structures, and
  4. Duplicate methods and unnecessarily complex design.

All these issues (and more) result from team-level decisions, not business prioritization. Two months into a project these decisions cannot be undone without business consent. Moving forward, however, the team can stop making these decisions. Instead of decrying the existing technical debt, the team can first focus on disciplined processes that will reduce (if not stop) the team’s decent into further technical debt.

Clarifying and enforcing the team’s definition of done is the best way I know to quickly reduce the team’s creation of technical debt. Specifically, the team needs to come to an agreement about the documentation, testing, refactoring, and other activities that must be complete before a task, user story or feature can be declared done. The team and its individual members must also be mindful to account for these activities during estimation, thus ensuring that there is time to do things right the first time.

Simply put, the team needs to start to tackle technical debt by first enforcing internal discipline and best practices. Once these are established, the team may be surprised to find itself on much more favorable ground when it comes to tackling business-generated technical debt.

Comments 1 Comment »

“Where do user stories come from?”

This is a question that I hear constantly from people new to agile development. Lots of places, is the stock answer. User stories — or features — really can come from everywhere, as anyone on the team may have a good idea and propose it. Another common answer to this question is the Story-Writing Workshop, which is a good technique for quickly collecting a diverse set of stories from many people. But when the team’s customer already has a decent idea of what he or she wants built, and no user stories have yet been collected, the Feature-Building Workshop becomes the sharpest tool in the shed.

This is also a great Iteration Zero activity. Read the rest of this entry »

Comments 2 Comments »

Sometimes agile teams have to draft and deliver scope, discovery, requirements or high-level design documentation. I don’t want to get into the how or why in this blog entry. Rather, I want to spend the entry discussing how these documents can be shaped as features and broken into discrete, estimated tasks so they can be prioritized, managed and tracked like any other development work in an agile process. Read the rest of this entry »

Comments No Comments »

This morning I met with a new team that has asked me to help them put some process around how they plan, manage and commit to work. This was our second meeting and the team is completely new to agile practices and techniques, so we started by shaping some of their work into features and breaking those features into tasks. Read the rest of this entry »

Comments No Comments »