A Few Ideas Regarding SCRUM Process

We’ve been using SCRUM at work. It’s certainly been a learning process. During that process I’ve learned that I’m not a very big fan of SCRUM. I’ll write more on that later. That said, I’ve come up with a few ideas which I hope will make my time, and my teams time, with SCRUM a bit better.

  1. Start measuring stories on complexity not time.
    It’s very easy for a story to be under-estimated. If a story is not estimated correctly, it will take longer and you will most likely miss your Sprint. Don’t think about time when estimating, we like to think we can get things faster than we actually can. Think, instead, about how complex something is. The more complex it is, the higher point it should get.
  2. Use a 10 point scale in your head when estimating.
    Depending on what you are using, the SCRUM point scale skips numbers. Our numbers are:

    0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100, INFINITY

    When we see numbers like 13 we immediately think that they are “big” numbers. So when we estimate we tend to pick numbers under 13 even though the story being estimated might require a 13. So, I say pick a number between 1 and 10 in your head and then translate that to the SCRUM numbers.

    0.5 1
    1 2
    2 3
    3 4
    5 5
    8 6
    13 7
    20 8
    40 9
    100 10
  3. Take the larger of any numbers present.
    I’ve dubbed this Jeremy’s law. During the course of estimating you might find yourself wrestling between a 2 and a 3 in your head. Take the bigger number. If there is any doubt in your mind, you should just take the bigger number instead of committing to something that you are not sure of.
  4. Look back at similar stories points. Did we complete them or were they underestimated?
    Previous stories you have completed might be similar to the ones you now have to do. Or they might have a similar complexity. Rather than estimating a whole new estimate, use that information to your advantage. If, in the past a story like this took a long time, it will probably take a long time again.
  5. Forget about doing it right the first time.
    This will be the hardest for me. I like to do it right the first time. But when it comes to SCRUM the key is to get stuff done. Once you have something done you can then iterate on it. Now – I’m not saying that you shouldn’t program using SOLID principles. I am saying that it’s easy to spend a lot of time analyzing things. Just jump in there and start coding it up.Think of the story as not having to be totally complete. Think of it as a step towards being totally complete. Just get it done as fast as possible. Than pass to testing. Once it’s done we can reiterate on it to improve it. But the first goal should be to get something out the door.
  6. Do create follow up stories (discovery stories for what is wrong)
    During a SPRINT review a stakeholder might not approve the story to go live. We should create a discovery story then and there to figure out what further they need from the story. Create new stories based on the results of your discoveries.
  7. Once a story meets ac it is done
    As long as the original story meets the acceptance criteria we can consider it done. Anything that changes the AC should yield a new story with new AC. This will allow us to iterate on the first while keeping the first story in a “done” state.
  8. Be more pro active about sending too complex stories back to be broken up further.
    Big stories need to be broken up. It’s just how it is. Don’t feel bad about sending a story back to be broken up.
  9. Don’t take in a thirteen if possible.
    In our version of SCRUM, stories that are 13 points will take up the whole Sprint. And because we know that things usually take longer than we expect, a thirteen will definitely overflow the timebox. So, send it back to be broken up.
  10. Pull smaller bits more often into master.
    There are certain bits of code that we add during the course of a project that can be added to master. We split the stories up, but maybe we can also split the code up as well. Instead of pulling a huge change into master, let’s identify the things that can go to master as we go along.
  11. Push things out as frequently as possible.
    Avoid the big pushes and potential big breakages by pushing smaller bits of code out more often. We talk about this often and say it is a good idea, but we don’t do it. We don’t need to get stakeholder approval to fix a bug we find, so push the bug fix live. We don’t need stakeholder approval to fix performance issues – so push those live. We don’t need approval to repay technical debt – so push that live.I’d reccomend we push anything live that we can. The stakeholders like to bundle everything up into a gigantic push. We really need to let them know that a better way to do it is a little bit all of the time.
  12. Immediately create stories for what needs to be done as soon as it is known.
    I think we as developers should be more pro-active about creating stories. If we find something that needs to be done, create a story for it. It’s hard to prioritize these kinds of stories because they are not necessarily related to business initiatives. So, use your best judgment in when to pull it in. The key is, it’s not going to get done unless we remember to do it.
  13. Always be thinking of ways to improve the process.
    Don’t be afraid to get rid of waste. If we get rid of the “big” waste, it enables us to see the smaller waste. If something is wasteful, don’t be afraid to get rid of it or let someone know you think it is time for it to go.

I really hope these things help. Ideally I’d like to move away from SCRUM. However, if I’m going to have to use SCRUM then I might as well figure out how to make it better.

Do you have any ideas on how to improve the SCRUM process? What do you do? How did your teams make things better?

Deserializing JSON to a .NET Object

Generally in .NET MVC you would use the default model binders to deserialize JSON to a .NET object. However, there are some cases, involving “complex” collections, where this becomes a bit tedious to do. Microsoft provides a few ways around this, but none are satisfactory. Unlike the default model binders, the JavaScriptSerializer provides support for deserializing JSON to a .NET object with complex collections.

Take the following simple class and method signature for example:

// simple class
public class SaveInformation
{
    public string Name { get; set; }
    public Dictionary<string, List<SaveItem>> Components { get; set; }
}

// method signature
public ActionResult Save(SaveInformation saveInformation)

Below I’ve included some simple JSON that we will pass to .NET via AJAX:

{"SaveToSession":false,"Name":"My Stupendous Thing","Components":{"Component1":[{"ProductId":"1234"}]}}

We are passing the JSON to .NET using AJAX with the “application/json” contentType. Because we are using the “application/json” contentType, .NET will automatically call the JsonValueProviderFactory and map the information over to our SaveInformation model. It seems pretty straight forward, the Save method will receive a SaveInformation object when it is called.

Not so straightforward unfortunately, the Save method does receive a SaveInformation object. If we inspect our SaveInformation object we see the Name is populated perfectly fine, but the Components dictionary ends up being null.

The reason for this? It seems that the JsonValueProviderFactory doesn’t fully support pure JSON syntax. In order for .NET to properly parse a complex collection, you actually have to give it a numerical index.

From http://msdn.microsoft.com/en-us/magazine/hh781022.aspx:

Though it’s somewhat counterintuitive, JSON requests have the same requirements—they, too, must adhere to the form post naming syntax. Take, for example, the JSON payload for the previous UnitPrice collection. The pure JSON array syntax for this data would be represented as:

[
    { "Code": "USD", "Amount": 100.00 },
    { "Code": "EUR", "Amount": 73.64 }
]

However, the default value providers and model binders require the data to be represented as a JSON form post:

{
    "UnitPrice[0].Code": "USD",
    "UnitPrice[0].Amount": 100.00,

    "UnitPrice[1].Code": "EUR",
    "UnitPrice[1].Amount": 73.64
}

I know right? It was hard for me to read this as well due to the anime-sized tears in my normal-sized eyes. The problem is, no browser I know of has a JSON.serializeForDotNet function. So this leaves us with two options, make our own JSON serializer, or make our own ValueProvider/ModelBinder. Neither of these options sounded very appealing to me, so I went with the hidden third option. Pass in a string :)

You can use the JavaScriptSerializer class, located in System.Web.Script.Serialization, to deserialize JSON information and, as an added bonus, it actually handles properly formatted pure JSON!

So, the new method looks like this. We pass in a string value and deserialize it using the JavaScriptSerializer. Now we receive a SaveInformation object with a fully populated Components dictionary.

public ActionResult Save(string saveInformation)
{
    // instantiate a JavaScriptSerializer
    JavaScriptSerializer serializer = new JavaScriptSerializer();

    // use the JavaScriptSerializer to deserialize our json into the expected object
    SaveInformation saveInformationObject = serializer.Deserialize<SaveInformation>(saveInformation);

URF! Ultra Rapid Fire mode needs to come back!

URF Login on April 1

URF Login on April 1

Riot introduced Ultra Rapid Fire mode into League of Legends on April 1 as an April fools joke. However, the community saw it as far less than a joke. The reasons that Riot gave for introducing URF included aboloshing “anti-fun”. I think they were on to something.

Here are the basics that were granted in Ultra Rapid Fire mode:

  1. Mana and Energy costs were removed (no need to manage that resource).
  2. Ranged champions attackspeed increased by 100%.
  3. Every champion begins the game with 80% cooldown reduction on abilities and spells.

This handy tool tip explains the gist of it:

The only way to play League anymore.

The only way to play League anymore.

There were some additional features I liked, movement speed was increased, so I didn’t have to buy boots every single game.

I played URF everyday since April 1st when it came out. I was very happy that (after the community begged and begged) Riot extended it for another week. But, alas, Riot ended it last night, April 13. I played one last game with ‘Vi’ which we won, and waved goodbye.

At the time I thought that everything would be fine. I’d go back to playing normal mode and it’d be just as fun as it was before. This morning I logged in and played a match with Vi on the Twisted Treeline map. It was very disappointing.

The movement speed was too slow, even with Boots of Speed. Waiting for cooldowns to proc was annoying. It took forever to build any items (even on Treeline). I was overwhelmed with a feeling of general frustration. The game had become less fun.

It used to be that I looked forward to playing League of Legends. However, when I think about playing League of Legends now I just feel extremely disappointed. I don’t really want to play anymore. It’s not that the game is bad, it’s a good game. But, after seeing how fun it could be it’s just not as interesting anymore.

Other people have noticed the same thing. The community is longing for URF to come back. Notice some of the response.

So with that said, I think I’m going to be taking a break from League of Legends. It’ll give me some time to finish some other games I’ve been needing to finish, like Tomb Raider 2013. Maybe I’ll come back later refreshed and find the game to be fun again. Maybe I’ll get fed up and program my own URF mode game. Or… maybe it is just time to say goodbye.

Pick of the Week for September 16 – Tonight Alive

I just heard about this band the other day from my one of my friends during a text conversation. He thought it would be right up my alley, and well he was right. The name of the band is “Tonight Alive“. They are a five piece pop punk band from Australia. That’s right, Australia!

Tonight Alive has been around since 2008, so I would consider them a newer band. Some people have compared them to Paramore… but I think they’ve got their own little spunk that sets them apart. In either case they are a good band and I think you should give them a listen.

The song I’ve picked is from the new album, “The Other Side”. The album was just released on September 6, so it is brand new! I’ve actually picked two songs off this album. The reason is, well I just can’t pick between the two!

The first song I’ve picked is titled “The Other Side”, it’s the title track off the album. I picked this song because of how heartfelt it is. You can truly feel the emotion put into the song, from the way that it is sung to the way that it is played. It’s a great song and you can listen to it below.

The second song I’ve picked is titled “The Fire”. It is the song that I originally intended to put on this blog before I started struggling with “The Other Side”. I really enjoy the crisp guitar in this song. I especially like the guitars in the bridge. The song is sung very well and I find myself wanting to belt out parts of it with the singer.

Buy “The Fire” here.
Buy “The Other Side” here.

The Other Side

The Fire

Pick of the Week for September 9 – blessthefall

Wow! It has been a long time. The good news is that we are finally moved into our new house (although I haven’t got my computer up and running yet, tonight!). We have been homeless since August 15 and it sure feels good to have a home again. I’ve been up late painting and moving things and changing locks and installing blinds. It’s been crazy!

Alright, so the pick of the week is a song called “You Wear a Crown but You’re No King” from blessthefall’s new album “Hollow Bodies”. It’s pretty dang good! Give it a listen below and let me know what you think in the comments section below! Do it!

Buy You Wear a Crown but You’re No King

Pick of the Week for August 12

The pick of the week is from Dispatch one of my top five all time artists. I’ve only said that about one artist before. One of the things that I’ve always thought was a bummer is that I didn’t start listening to Dispatch until after they decided to call it quits! Yep! I started listening to them in 2004 after one of my friends introduced me to them. This just happenned to be right after there farewell concert, which, according to there website, was the largest independent music event in history. Needless to say, but I will say it anyways. It was only a few weeks before I had all of there albums.

This song comes from there first album, Silent Steeples. Silent Steeples is probably my favorite album by Dispatch. Each of there albums has a unique sound to it. Silent Steeples is more accoustic/folk rock whereas Bang Bang had more of a reggae/ska influence to it.

Well, I would love to go on and on about Dispatch, but I should probably just post the song already! The name of the song is “Bridges”. You can buy “Bridges” by Dispatch here or listen below.

Owl City to be Blamed for Recent Popularity of Electronically Driven Music

I just thought I would post this here while I was thinking of it. I believe that Owl City is to blame for the recent propagation and proliferation of electronic and keyboard driven music making it’s way into the mainstream. Granted, keyboards and synths have been around for a long time and have always had a following. But I believe that keyboard and synth driven music is just going to become more popular over the next few years. Adam Young, I believe, was the catalyst that helped spawn this growing trend in the popularity of electonically driven music.

So let’s say a big thanks to Owl City. Personally, I think the world could always use more keytar.

Taco Bell Removes the Enchirito from Menu

**EDIT 09/20/2013 **

I recently went back to Taco Bell. As it turns out they have put the Enchirito back on the menu. When I asked why, they told me that a lot of people were unhappy and wanted it back. So good work people!

**END EDIT**

Oh Taco Bell. You have done this to me before and you are doing it to me again. When are you going to learn that taking things off your menu is a BAD thing? It is especially bad when you “take” something off the menu and replace it with the same thing albeit more expensive.

A couple of years ago Taco Bell removed the Nacho Cheese Chalupa from it’s menu. (It was probably a couple of years ago although it could’ve been more recently). This made me mad. Let me tell you what I say when I order from Taco Bell. “Hi Taco Bell Person, I’d like 2 bean burritos, a Nacho Cheese Chalupa and an Enchirito”. That’s it! That is what I always had. So imagine my surprise when one day I say my normal order and the response from the other end is “We don’t sell Nacho Cheese Chalupas anymore.” And so I said, “What?…”.

What?...

What?…

Well that was a bad day. But I quickly learned how to get around it by being a super annoying customer. That’s right, my future orders went a little like this.

I’d like two bean burritos, a Nacho Cheese Chalupa, and an Enchirito please.
We don’t sell Nacho Cheese Chalupa’s anymore.
Oh really…? Hrmmm. Well then I would like a Supreme chalupa with no sour cream.
No sour cream?
Yes. No sour cream. Oh and can you add Nacho Cheese to that too?
A Supreme Chalupa with no sour cream and nacho cheese?
Yes.

So, in case you are wondering how to get a Nacho Cheese Chalupa, that’s how.

So… same story no happy ending yet. Today I go to Taco Bell and I order my order. This time they say “We don’t sell enchiritos anymore”. And so I said “What?…”

What?...

What?…

So, as it turns out, they are selling Enchiritos, they’ve just renamed them and made them more expensive. They are now called “Smothered Burritos” and they come with Sourcream on them in addition to the normal stuff. Can you say argggggg? I can. You should try it, I think you probably could.

I’m sure I’m not the only one who thinks it’s LAME to rename an item on your menu and make it more expensive. Then again I guess they can do what they want to do… be stupid.