I just can’t get enough of Conversational Interfaces that do the job for me – and they do it well. I think that most of the businesses haven’t really tapped into CIs (at least in Finland), but I think that those who have, will realize that conversational interfaces are likely to cause a major shift. At the time there are limits to using CIs but they are getting better, and better as time goes forward.
Boksishop on täysin uudenlainen rautakauppakonsepti, joka pohjautuu shop-in-shop-idealle. Haastattelin ensimmäisen myymälän suunnitellutta Pikku Apurin Jari Liitola, joka kertoo nyt, kuinka pienienkin kuntien keskustoihin voidaan saada uutta liiketoimintaa esimerkiksi rautakauppojen franchising-Boksishoppilla.
What development Branch to cut?
This is a question that I hear a lot these days from Product Owners. First, to start with I skip the part where you have set your game plan accordingly to the impact you are looking for. Let’s all assume that you have a guiding idea of how to proceed with the implementation. Woop Woop! So it’s time to look one way to measure development called – Theme scoring. I will try to guide you throw quite simple but effective model to measure your different development branches.
One way of structuring requirements
We all have usually different needs in our software development. In this blog post, I try not to go too deep end of those needs. But just to be sure here all game plans should include the impact that you are looking for and is the basis for prioritization. Examples of these looked for impacts usually can be;
- Faster time to market
- More users
- More revenue from users
- Increased customer loyalty
- Better competitive position
- Increased operational efficiency
- (all above should be expressed with numbers)
I try usually make these more ”human-like” such as – bite the feature – money first – volume first – risk first – one user group first etc. You get the picture. This clarification to game plan usually brings a nice balance between biz needs, risks and feasibility of technical implementation. Now that you have your themes ready let’s look at where they should be placed.
Time to do Theme Scoring
This will take some time to do as theme scoring takes into the different importance of each selection criteria. Each criterion needs its own baseline to start with. Then it’s just assessment of each theme against the baseline for each selection criteria. Let’s start with creating the criteria.
|Much worse than reference||1|
|Worse than reference||2|
|Same as reference||3|
|Better than reference||4|
|Much better than reference||5|
As we can see above your theme Theme A, Theme D & Theme F are not worth to continue with this selection criteria. Instead of those, you should focus on Theme E, Theme C & Theme B. Simple, right? Usually, this ain’t as straightforward and Selection criteria can change even between themes as we all are dealing with stakeholders. If you need a theme scoring template you can use this one LINK
Couple words about using Theme Scoring
First – I would like to give you a heads up about time usage. I strongly recommend that you deal with development teams, product managers, management & other stakeholders when you are scoring your themes – This takes time I’m afraid. Secondly, make sure your Selection Criteria is right! When choosing one I try to reflect it on the game plans that I have on each branch. And finally, make sure you build feedback loops around your theme scoring. In that way, you are always one step ahead when it’s time to make the decision about ”what branch to cut”.
Have fun and I’m more than happy to help if you need any assistance in measuring your software development!
As I’m writing this there are around 12,000 public, open APIs and a large number of private systems. We can say API economy has exploded rapidly. IoT (Internet of things) devices become ubiquitous, using APIs (application programmer interfaces) to transfer data between users and systems. For us this has become business as usual. The urgency to create new business models are the factors behind such a rapid growth.
…mutta se ei tarkoita että meidän pitää lopettaa sen tekeminen. Totesi pragmaattinen Dave Thomas esityksensä alkuun. Thomas on yksi alkuperäisistä Agile Manifeston kirjoittajista ja yksi pragmaattisen ohjelmistokehityksen & ketterän -kehityksen sanansaattajista. Jos et seuraa aktiivisesti ”agile skeneä”, niin taustaksi pitää vielä mainita ehkä muutama asia.