Pair programming; sorry, pair reading!
Read More
Announcing agileTwitionary – a marriage of Twitter bird and the Dictionary !
Our intent here is to bring very concentrated doses of agile terms’ definitions. These twits will take out all the unnecessary information from definitions of agile terms, focus on the essence and key ingredients of the it, create a concentrated potion and deliver to your mobile devices!
How to get this potion? Just goto www.AgileTwitionary.com, follow us @agileTwitionary, or look for hash tag #agileTwitionary
To these concentrated doeses of this potion, along with agile terms, we will also be adding brief about:
- Personalities that are shaping agile world
- Alphabet soup – Accronyms that you may run into
- Agile tools
This has been a fun project for us, and we think this daily, concentrated doses will benefit you, and add a little bit more value to your day! So, start hearing the chirps from @agileTwitionary !
P.S.
Got any comments? We would love to hear from you. Shout out at www.AgileTwitionary.com or send us email at admin@agileTwitionary.com
Announcing agileTwitionary – a marriage of Twitter bird and the Dictionary !
Our intent here is to bring very concentrated doses of agile terms’ definitions. These twits will take out all the unnecessary information from definitions of agile terms, focus on the essence and key ingredients of the it, create a concentrated potion and deliver to your mobile devices!
How to get this potion? Just goto www.AgileTwitionary.com, follow us @agileTwitionary, or look for hash tag #agileTwitionary
To these concentrated doeses of this potion, along with agile terms, we will also be adding brief about:
- Personalities that are shaping agile world
- Alphabet soup – Accronyms that you may run into
- Agile tools
This has been a fun project for us, and we think this daily, concentrated doses will benefit you, and add a little bit more value to your day! So, start hearing the chirps from @agileTwitionary !
P.S.
Got any comments? We would love to hear from you. Shout out at www.AgileTwitionary.com or send us email at admin@agileTwitionary.com
As described by Mike Cohn, a User Story has several components to it; and the Description should be written in following format.
As you can see, this format basically focuses on three parts: role, action, and value creation. You would be looking to collect the requirements while starting on a new project. And, you have an unlikely ally, a partner in the form of UML – the Unified Modelling Language that can help you with this. UML can help you in your quest for collecting meaningful user stories.
Anytime you start discussion of any application, you will start with Context diagram for the proposed solution. Context diagram, in essence is a diagram showing your proposed solution and all the players that will interact with this solution. I have found this (context diagram) to be extremely useful in getting the requirements gathering going.
Let’s look at an example. In my book, Agile Release Planning, I talk about an example project of creating a website www.nflFans.com to act as web portal where all football fans can buy and sell game tickets. As part of the lightweight requirements gathering, I would have my team start with the central idea; putting a box in the center to show the future proposed solution.
Now, start discussing the interactions and all the actors that would be interacting with this proposed application. There are several roles and actors, human as well as non-human, that will interact with app. Actors such as Football fans, our web portal as a system, credit card companies for credit card processing, Football teams for providing seat availability, etc. As you discuss various interactions, continue capturing the actors into this context diagram. Now, the context diagram looks like this.
If you overlay User story format on top of this diagram, you will realize that this context diagram give you the first part of your user story As a/an.
UML helps you keep the discussion at a high level, rather at the right level. In the next episode we will talk about extending this context diagram to get second part of the user story using this lightweight requirements gathering approach.
As described by Mike Cohn, a User Story has several components to it; and the Description should be written in following format.
As you can see, this format basically focuses on three parts: role, action, and value creation. You would be looking to collect the requirements while starting on a new project. And, you have an unlikely ally, a partner in the form of UML – the Unified Modelling Language that can help you with this. UML can help you in your quest for collecting meaningful user stories.
Anytime you start discussion of any application, you will start with Context diagram for the proposed solution. Context diagram, in essence is a diagram showing your proposed solution and all the players that will interact with this solution. I have found this (context diagram) to be extremely useful in getting the requirements gathering going.
Let’s look at an example. In my book, Agile Release Planning, I talk about an example project of creating a website www.nflFans.com to act as web portal where all football fans can buy and sell game tickets. As part of the lightweight requirements gathering, I would have my team start with the central idea; putting a box in the center to show the future proposed solution.
Now, start discussing the interactions and all the actors that would be interacting with this proposed application. There are several roles and actors, human as well as non-human, that will interact with app. Actors such as Football fans, our web portal as a system, credit card companies for credit card processing, Football teams for providing seat availability, etc. As you discuss various interactions, continue capturing the actors into this context diagram. Now, the context diagram looks like this.
If you overlay User story format on top of this diagram, you will realize that this context diagram give you the first part of your user story As a/an.
UML helps you keep the discussion at a high level, rather at the right level. In the next episode we will talk about extending this context diagram to get second part of the user story using this lightweight requirements gathering approach.
Read More
Tool Kit..
I talk about toolkit in my book Agile Release Planning to help you manage and facilitate various sessions of release planning for your project/program. This tool kit includes various items such as Marker pens to Flip charts that will help you better facilitate these sessions.
Here is the list of items that I like to include in my tool kit.
Do you use any specific item(s) that you would like me to add to this tool kit?
Read MoreTool Kit..
I talk about toolkit in my book Agile Release Planning to help you manage and facilitate various sessions of release planning for your project/program. This tool kit includes various items such as Marker pens to Flip charts that will help you better facilitate these sessions.
Here is the list of items that I like to include in my tool kit.
Do you use any specific item(s) that you would like me to add to this tool kit?
Read More
We all are familiar with these dials! This is a picture of my car-dashboard, giving me reading on various aspects of my car and my driving (habits). Do you have a dashboard that you use to navigate your Agile projects through the real life challenges? If you do have it, what are the dials you use on it?
If you don’t have the dashboard for your project, at a minimum, I would strongly suggest of posting this dial (shown below) to show the productivity of your team.
Essentially, it is tracking what Value you are creating (BV) against all the Effort (SP) you are putting into it. As mentioned on Wiki, Productivity is a measure of the efficiency of production. Productivity is a ratio of production output to what is required to produce it (inputs).1
You can consider it your team’s Productivity Index (PI).
I like to chart it on a scale of Zero (0) to Two (2). If your team stays on the left of the dial, your team needs to work on improving the velocity and productivity. On the other hand, if your team stays on the right side of the dial, your team is producing more than what it is taking in. If you are staying somewhere in the middle of the dial, your team is breaking even.
Here are PI dial for three different teams:
 Team “Silver”
|
 Team “Gold”
|
 Team “Platinum”
|
Which team would you rather have? Which team would be proud of coaching?
Notes:
BV=Business Value
SP=Story Points
PI=Productivity Index
We all are familiar with these dials! This is a picture of my car-dashboard, giving me reading on various aspects of my car and my driving (habits). Do you have a dashboard that you use to navigate your Agile projects through the real life challenges? If you do have it, what are the dials you use on it?
If you don’t have the dashboard for your project, at a minimum, I would strongly suggest of posting this dial (shown below) to show the productivity of your team.
Essentially, it is tracking what Value you are creating (BV) against all the Effort (SP) you are putting into it. As mentioned on Wiki, Productivity is a measure of the efficiency of production. Productivity is a ratio of production output to what is required to produce it (inputs).1
You can consider it your team’s Productivity Index (PI).
I like to chart it on a scale of Zero (0) to Two (2). If your team stays on the left of the dial, your team needs to work on improving the velocity and productivity. On the other hand, if your team stays on the right side of the dial, your team is producing more than what it is taking in. If you are staying somewhere in the middle of the dial, your team is breaking even.
Here are PI dial for three different teams:
|
Team “Silver”
|
Team “Gold”
|
Team “Platinum”
|
Which team would you rather have? Which team would be proud of coaching?
Notes:
BV=Business Value
SP=Story Points
PI=Productivity Index
An interesting thought came to mind when I was explaining User Stories to one of the team I am coaching. There are some guiding principles and practices that we must follow to be successful in writing and executing the User Stories. These are what I call commandments of writing a USer Story.
Read More
What do we mean by Commandments? Let’s first look at the definition of “Commandment”.
The commandments could be a religious or moral imperatives; they act as “guiding lighthouse” to a purpose, and you hope to live by those commandments to reach certain purpose in life. In essence, they are guiding principles for individuals you hope to live by.
Similarly, in Agile projects, the purpose is to deliver business value; in small increments with each iteration. User Story is the neucleus of Agile project and success of the project heavilty depends on them. I belive there are “Ten Commandments of User Stories” that will help any team venturing on the Agile journey and guide them to success.
So, here they are: the Ten commandments of User Stories
- Thou must deliver Business value
- Thou must prioritize User Stories based on Business Value (by Product Owner) and Team must take collective ownership
- Thou must be validation centric
- Thou must be “Done Done Done”
- Thou must have 3Cs
- Thou must be Crosss functional (california roll)
- Thous must INVEST in User Stories (the six attributes)
- Thou must Size and Estimate (using Story points)
- Thou must Swarm (and complete few stories at a time)
- Thou must post Story Burnup chart
<![]()
> WoW (Word of the Week)
Announcing WoW! Word of the Week!
I am starting this new series, and as part of it, I will take one word/terminology every week, that we use in Agile world and attempt to explain it quickly, briefly in lay men’s term, without boring you all 🙂
My objective here is to increase awareness of these terms, and share my knowledge with you all. My hope is that it will empower you, enlighten you, increase your knowledge about various terms that we use in Value driven approaches such as Agile and Scrum. This will help you work towards increasing value and RoI for your customers.
I promise you that reading it won’t take more than 5 miutes of your time, and I gaurantee you that it will add value to your day/week. I will publish this in the middle of the week; every Tuesday night as a post on my blog, and send out Twit notification about the post. Please follow me on @beyondCSM for the weekly updates; or check out my site www.AgileReleasePlanning.com
Read More
I used this software tool to complete documentation at one of the Client site I recently worked at. Rather than create long, boring MS Word documents, we created short Videos ‘showing’ how to complete certain tasks/activities. The software is available free of charge here.
The only catch with the free edition is that you can not create a video longer than 5 minutes. This limitation, though, works to your advantage as anything more than 5 minutes would get boring. This forces you to keep the video short, forcing you to pack more ‘punch’ within this 5 minutes.
This, obviously, does not replace the Word documents, but rather is an extension of Word documents and makes them ‘light weight’. And, this tool makes the documentation process more fun!
Now onwards, enjoy the (dreaded) documentation!
Read MoreI used this software tool to complete documentation at one of the Client site I recently worked at. Rather than create long, boring MS Word documents, we created short Videos ‘showing’ how to complete certain tasks/activities. The software is available free of charge here.
The only catch with the free edition is that you can not create a video longer than 5 minutes. This limitation, though, works to your advantage as anything more than 5 minutes would get boring. This forces you to keep the video short, forcing you to pack more ‘punch’ within this 5 minutes.
This, obviously, does not replace the Word documents, but rather is an extension of Word documents and makes them ‘light weight’. And, this tool makes the documentation process more fun!
Now onwards, enjoy the (dreaded) documentation!
Read Moreshare the #Wisdome
