Click here to Skip to main content
11,574,494 members (68,716 online)
Click here to Skip to main content

Tagged as

Continuous thinking: Nerdbeers - Providing business value by issue tracking

, 31 Mar 2011 CPOL 3.7K 1
Rate this:
Please Sign up or sign in to vote.
Note: this post is part of a series; you can find the first post here.IntroductionWell, another 14 days passed by for the NerdBeers project, and a lot has happened:@Grumpydev added a proper designI did some major refactoring in the FailingSqlite branch, which will allow us in the future to have full

Editorial Note

This article appears in the Third Party Product Reviews section. Articles in this section are for the members only and must not be used by tool vendors to promote or advertise products in any way, shape or form. Please report any spam or advertising.

Note: this post is part of a series; you can find the first post here.

Introduction

Well, another 14 days passed by for the NerdBeers project, and a lot has happened:

  • @Grumpydev added a proper design
  • I did some major refactoring in the FailingSqlite branch, which will allow us in the future to have full integration testing available for doing proper BDD (or top-down TDD, if you prefer to call it like that). Unfortunately this branch is still pending for integration due to some problems.
  • I got some followers/forks over at github (Yay!!)
  • Some more people offered to help me out
  • Both @MarkRendle and @NotMyself progressed a lot with both Simple.Data and Simple.Data.SQLite
  • Spring started; I enjoyed the sunshine outside with the kids and the Mrs.
  • Social obligations
    • My brother in law's house renovation deadline is approaching
    • My brother's birthday party
    • Lots of catching up with some friends
    • ...

So Nerdbeers has not really changed a lot ? Are you lamenting ???

No, in fact I am not, I spent quite a lot of time on trying to get the "FailingSqlite branch" going, but unfortunately I have not been able to finish it, so I can not integrate all my changes into the master branch.

After receiving a kind offer from someone to help me out on the project, he asked me what still needed to be implemented. This got me thinking:

In this project, I reject tools/methodology as long as possible. Since I noticed the project was starting to slip - I've spent a lot of time on it, but the Net result for the end user is still zero -, I wondered how I could prevent this from happening again.

After all, that is what Agile/Lean is all about: be as efficient as possible in what you do, and the minute you are getting less efficient, look back at what happened, and find a way to make sure it does not happen again.

I used this approach all the time in the Nerdbeers project: I started without any tests or IOC, I postponed them until the manual testing process was slowing me down/not error-prone enough. This might mean I have a suboptimal design, but since there is no real business value in this, I can safely neglect this. When the suboptimal design starts getting in the way of doing efficient development, I can always refactor.

Anyway, back to the slipping part.

How can I prevent this lamenting stuff ?

The reason for lamenting is quite straightforward: I need a proper way to determine my - and the contributor's priorities. So I started creating issues on github, and after a few attempts of tagging, I finally found a method that works for me. It is heavily inspired by the Kanban stuff I use all the time during dev.

This is what the open issues list currently looks like:

 

Whoa, that's a lot of tags!! Why is that ?

Well, because I need them; let's look at them one by one, in the order they are assigned:

  • Type: determine whether an issue is providing direct business value (bug or feature) or not (Tech)
  • Time: a very rough estimate how much time it might take to implement; the purpose is helping you prioritize issues
  • Care: this tag points to the person who is taking care of this issue (you could consider this a bit like an assignment)
  • Stat: (short for status) Using stat you can follow the progress of the task

I tried searching for the minimal amount of tags which would allow to determine the correct priorities.

Using these tags I found out that the huge branch I'm currently working on, does not really provide a lot of added business value, so I decided to lower the priority and make it a bottom one. This is actually something that happens a lot with projects: things get implemented because they are "cool", but they actually do not provide a lot of direct business value. These tags should help me to prioritize.

Another cool thing is that the closed issues list now actually provides some value:

 

Fixing the features

As I was thinking about all the possible features, I noticed that I was adding a lot of them, without actually thinking them through. Since I wanted to avoid adding features which do not provide business value, I decided to implement a BDD technique into my feature definition.

Lets take a look at this in detail:

<span style="TEXT-DECORATION: underline">As a</span> site owner
<span style="TEXT-DECORATION: underline">I would like</span> the Nerd
<span style="TEXT-DECORATION: underline">To be able to</span> view a map of all upcoming nerdbeers
<span style="TEXT-DECORATION: underline">So that</span> he can choose whether he would organise one himself, or just join another one

This uses my favorte BDD format for BDD stories: you inform the reader who wants the feature, for whom it is designated, what it is and what the business value is.

This approach actually made me remove some of the issues I had entered, and made me alter some others. Someone who looks at a feature should now be able to figure out a lot based on these four simple sentences.

Conclusion

While the app in itself has not really evolved a lot, the way we approached it now has; this is what Agile/Lean is all about to me: provide business value in small incremental steps, reducing waste/being efficient as much as you can. I am rather curious to know what the next step will be in this project !!!

 

Bookmark and Share<script type="text/javascript" src="http://s7.addthis.com/js/250/addthis_widget.js#pub=xa-4aec37702e3161d4"></script>

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Tom Janssens
Founder Core bvba
Belgium Belgium
Tom Janssens, owner of Core, a software and consultancy company.
Father of two sons named Quinten & Matisse, and married to a beautiful woman named Liesbeth.

Blog: http://tojans.me
Github: http://github.com/ToJans
Twitter: http://twitter.com/ToJans
LinkedIn: http://www.linkedin.com/in/tomjanssens

You may also be interested in...

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.150624.2 | Last Updated 31 Mar 2011
Article Copyright 2011 by Tom Janssens
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid