User Role Modeling..is this really required?

Any business requirement that needs to be formulated in user stories can be best justified if the writer knows the user roles for which the requirement will be mapped. To identify users, user role modeling is important. For example, if we want to develop a direct-sales website, we must keep our focus on buyers, sellers, admin, executives, etc. When the user roles have been identified, then the requirements can be mapped to user stories, keeping each identified user in view. More effectively, if we can associate a persona for each user, it helps broaden the thought process for that particular user, and it results in effective story writing. As the saying goes, "put yourself in someone else's shoes."

 

 Following is an example of a requirement and how to visualize it from different perspectives:

 

Requirement: To make a toy train for kids.

 

 What all are the user roles here?

• Kids (obviously)

 

. . . and. . . ?

 

• Parents
• Toy manufacturer (yes, sometimes we need to consider the manufacture also)
• Anyone else whom we can tie to this requirement (later users with the same requirements can be merged and one role can be chosen)

 Once the user roles have been identified, effective user stories can be written. Below I have provided role-specific sample user stories. These user role-specific stories not only help developers understand the requirements of the feature but also help QA identify the scope of testing.

 

Expectations related to different user roles:

 

• ·         As a child, I want to see the toy train in attractive colors so that I crave it.
• ·         As a child, I want to have fun using this toy with my friends so that I will enjoy it for a long time.
• ·         As a parent, I want to be excited by the look of the toy so that I will purchase it for my child.
• ·         As a child, I want to count the compartments of this train so that I can learn counting also.
• ·         As a manufacturer, I want to provide my information on the toy box so that customers can contact me to buy other toys from me.
• ·         As a parent, I want to be sure that the toy has no sharp edges that might hurt kids.
• ·         As a parent, I want to verify that this toy is appropriate for kids two to three years old (my kid's age group) so that they are able to understand it and like it.
• ·         As a parent, I want to buy a nontoxic, excellently made toy so that it will be safe for kids.
• ·         As a parent, I want to learn about the manufacturer of the toy so that I can buy more toys from them.

 

 More expectations (or user stories) can be added here. Also, a few can be merged, or "conditions of satisfaction" can be added to one user story. For example, "nontoxic, excellent grade of plastic" and "no sharp edges" can be taken up as conditions of satisfaction.

 

 Now tell me which user has the highest set of expectations for the toy. Children?  :-)

The Misinterpreted Developer!

The term "developer" is not meant only for programmers. However the term developer became so popular in the last decade that it became a synonym for programmer. That's no surprise, given the way programmers welcomed the tag. However, developer has a broader sense in Scrum teams. Not only programmers but also testers focus equally to develop and deliver a quality product that provides some business value. This is the reason that in Scrum that there is only a "development team," regardless of programmers or testers. Organizations may have a separate team of testers or QAs, but the role defined in Scrum is "developer" only. Here I am only concentrating on programmers and testers. In reality, combinations of other roles, including designers, content writers, and business analysts, constitute the Scrum development team. This development team is formed with cross-functional developers with t-shaped skill sets.

 In Waterfall (command and control), it is a general practice to have different teams of programmers and testers. The higher the number of bugs found during testing, the more it is a sign of effective testing. The cubicles of testers are purposely kept at a distance from those of programmers. No casual discussions during features-functions implementation!

 Programmers used to send their tentative plan of providing builds to testers, and testers used to provide the test results as per their schedule. A cold war could be felt during this phase. Even simple bugs that could be fixed in a negligible amount of time lasted for a significant duration. This was a dark side of command and control!

 In Agile practices, the developers (programmers and testers) work toward development of a product/service and deliver some business value in a shorter duration, resulting in increased return on investment. Now, how does Scrum work to make that happen? On a Scrum team, developers work with one aim, and that is to deliver quality chunks during the timeboxed sprints. On the Scrum team, the tester is not the one who tests the tasks; the programmers or other development teammates also help in testing. Recently on one Scrum team I found tasks named "QA <task> by developer." The word developer was odd here, but the idea of sharing the load of testing was precise, and this is the only way of completing quality tasks in the timeboxed sprint.

 The role of testers becomes more interesting and challenging in Agile teams. Testers help other members of the development team understand the requirements and the different angles for testing the functionality/tasks. This helps other teammates broaden their testing skills. The same happens when programmers share some tidbits of programming.

 This is best achieved through pair testing. As pair programming is generally meant to mean two programmers working at one workstation, pair testing is carried out with one programmer sitting with one tester. The tester continuously tests the completed task with the programmer, and if any fixing needs to be done, it is done then. Again, there is not a rule that only a tester will be paired with a programmer during pair testing; in fact, any teammate can perform this role.

 So the next time we use the term developer, will we only have programmers in our minds?

Very soon we will go through CI (Continuous Integration), a very important aspect during sprints.

Stay tuned!

Whiteboard during Meetings…

  In Scrum meetings, participation of team members, and specifically participating together, is important. At times, however, participation is not balanced in a meeting. A few members actively speak, while others only listen. (Highlighting this point does not mean that listening is not good.)

 There are several reasons why some team members do not participate in meetings, but one of the main reasons for new Scrum team members is that they are shy to speak. This discussion pertains only to these situations.

 ScrumMasters use spreadsheets, electronic tools, or sometimes whiteboards for recording the ideas presented by members at meetings. I prefer the whiteboard because it is not only a good way to record the ideas but also everyone can see these ideas easily. This method of visualization also increases active speaking and participation of members, because when the ideas are visible on the whiteboard it spreads the message, "Your idea is valuable." When members see that their ideas are valued, not only do they feel valued but others also get motivated.

Second, we retain clear, visual ideas longer in our minds, and we avoid redundancy. You can use symbols, signs, or whatever else works.

Despite other means of capturing meeting notes and ideas, the significance of the whiteboard remains. However sometimes it becomes necessary to use other means apart of whiteboard for example, if team is distributed at different places use of electronic means becomes inevitable. Still for local discussions whiteboard may be used.

Here are some do’s and don’ts for the uses of whiteboard.

Do's:

Use block letters, as they accelerate reading speed.

Use alternate-colored markers.

Use black, green, blue, brown, or purple for easy-to-read text.

Use red, orange, or pink as highlighting colors.

Use only standard abbreviations.

Don'ts:

Avoid color coding, as in the flow of discussion it becomes difficult to manage.

Avoid small fonts that may be difficult to see by the members sitting farther away.

Finally:

When you need to erase the ideas/notes from the whiteboard, capture a snap on your   mobile phone so that you can refer it later. Encourage team members to do the same for their own future reference. This will give them freedom from taking notes during the meeting, so they can concentrate only on the discussion.

Quality test procedure in two week Sprints? Don’t you play Cricket?

     Two week Sprints. Why not? I compare it with Cricket. When ODIs wrapped the show of five day test matches and then came the 20-20 with more excitement, didn’t we welcome? Quick ROI (return on investment), result oriented and happy stakeholders. :-) 

To ensure delivery of shippable increment with each iteration, programmers look at each story and related tasks to identify the most necessary tasks of the functionality. Those tasks are completed first and then subsequently the rest tasks of the functionality are taken up. The idea here is that instead of delivering nothing of that functionality at the end of the sprint, at least deliver something which works.

Agile testers take the same approach and identify the happy path of the functionality first and start by making sure the happy path works.  And this statement does not indicate to leave the negative tests. Negative testing is vital for quality product. A good approach is to automate the happy testing and once found fine then go ahead with negative testing. However this is very necessary to identify the criticality of the product.

If any defect which is not observed in normal circumstances i.e. to produce a defect it takes various tricky steps which are almost unusual, then it is worth to leave fixing those. To stop the delivery may impact on ROI (return on investment) and one of the good things in agility is early ROI. But yes, this defect needs to be indicated to Product owner. It can be considered as a technical debt and may be re-paid later, if felt necessary. This practice is acceptable in short sprints.

In scrum teams, programmers work using TDD (test driven development) and ensure positive scenarios are working fine. Testers write regression test scripts. The development team which comprises of programmers, testers, designers and sometimes business analysts also, execute these test scripts during the last two days of sprint. Certainly the teamwork during sprints plays a major role in delivering quality chunks in such a short period. And this all get possible with the help of automated tools and continuous integration.

In my future articles we will be exploring such tools used in scrum teams and the continuous integration.

So stay tuned…

Game of Imagination!

     We all know that Scrum games are helpful in building team cohesion, energizing everyone, and breaking the ice for shy teammates.

Here is a game that I found very interesting and easy to play. I got the idea for it from the thematic apperception test (TAT).

Necessary materials:

1. One large blurred image, which should show one person doing some activity. This image should be blurry enough that the team can imagine any human presence but cannot definitely identify who the person is and what exactly he or she is doing. For example:

That image may be shown:

• Through a projector.
• On a big screen in a conference hall connected to a laptop or PC.
• On a flip chart, pasted or drawn on.
• On a whiteboard, again pasted or drawn on (drawing a blurred image may be a tough job!).

2. Writing pads/papers for teammates

3. Pencils/pens for teammates

How to play:

1. The facilitator will ask each development teammate, "What would you be if you were not IT personnel?"

There will be different answers given, such as:

• Doctor
• Air force pilot
• Police officer
• Businessman
• Professor
• News reporter
• Poet/singer/guitarist
• . . . And you can add some unusual, imaginary roles as well.

 

2. The facilitator then shows the image and asks each team member to write a story about that image, related to the role each chose for himself or herself. The story should be five to seven lines long only. (Give a time limit of six minutes: one minute to think and five to write.)

3. Once everyone has finished writing their stories, the facilitator will ask each team member to narrate the story he or she has written.

4. After finishing the story-telling round, the facilitator will disclose the "real" role of the person in the image. This role will be the choice of the facilitator, preferably a role that was not among those the teammates listed in the beginning.

5. The facilitator will now ask the team to collaborate on writing a single story about the image, bearing in mind the role the facilitator named. It should contain ideas from each team member and be 10 to 12 lines only. (Time limit: 20 minutes, 5 minutes for discussion and 15 for writing)

6. The team will select the narrator of this story. The narrator may be the last one who entered the meeting, or decided through a draw, or whatever the team decides.

No conclusion will be given for any story. The image contents and theme used in one game may be modified for games in the future.

This exercise will not only be refreshing but it will also give wings to the imagination of team members.

A few explanations:

• Why individuals need to narrate the story?

 Narrating story will work as an ice-breaker for shy team-members.

• Why writing story two times, one individual and one group story?

First story will be individuals thought and will solely intended as an ice-breaker. The second story will be the result of team-work and team-cohesion.

• Why the image needs to be blurry?

If the image will be clear then it will stop the imagination from the team-mates. For example, if we see a person in army uniform then it will be tough to write a story on a doctor, at least as an active actor of the story. Same will apply when the second story will be discussed and written.

• What does ‘story’ imply here?

Story here means a few sentences on the role. For example- Harry is a teacher. He goes to nearby village over weekends and spread literacy. He does this free of cost ….continue with your imaginations.

• Why the facilitator will select a different role that was not listed in the beginning.

If the role is among the roles listed in the beginning then the story is already there.   The idea for a common story here is to ignite the team-work and cohesion, in action!

Please feel free to ask for any further explanation needed for this game.

Scrum meetings! huh.. I’m not interested...

Have we ever felt that scrum meetings are waste? If the answer is yes, then we need to identify the reasons for that.

Why should we attend scrum meetings? Such concerns are often raised within scrum teams.

There are several reasons that scrum team member feel that such meetings are waste of time.

Let us take example of estimations.

A common problem with a new scrum team can be seen during estimations. It is generally observed with teams transform from waterfall to agile. In such teams, veterans dominate the estimation process and their estimates are finalized. Sometimes the situation gets worse where only veterans/specialists estimate and make a commitment. Junior team members are not involved during estimation. One of the reasons is at times most of the team mates of new agile team had worked together in some projects which followed waterfall methodology and accepted that the ways estimations were done and committed, the specialists know better.

While sometime it is taken as granted in new and immature agile teams, which do not have understood the significance of all the ceremonies of agile, some team mates feel that once the decisions have to be made by these specialists and they will be dominating the ceremonies, what is the use of attending such ceremonies?

Annoyed team mates feel that instead of attending these ceremonies they can put this time for some other purpose.

One other reason is being monotonous and not creating enthusiasm in these ceremonies. Ceremonies are for Transparency, Inspection and Adaptation and when due to any reason, no significant outcome or improvement is visible, it creates dullness.

This is true that apart of other responsibilities, facilitator needs to be energetic and innovative. Bringing new scrum games also play great role in such cases where team mates show unwillingness to join the ceremonies due to such dryness.

ScrumMasters/facilitators need to sense such alarming situations well in time and take the appropriate action before it gets late and spoil the team bonding. ScrumMaster also need to encourage all the team mates time to time, not to participate but participate together in scrum ceremonies.

Agility everywhere!

 

Our annual day function was nearing and our CEO announced to make it big.

The HR team and the cultural team were indicated to plan a big bash. Fortunately a few members of the cultural team are part of one of my development team. This team is comparatively new to agile and I got a chance to provide them this opportunity as a scrum game.
The pitch was ready.

·          They had a vision: Vision from our CEO - ‘Let us have a grand Annual function party!’

·          There were stakeholders: CEO, VP, AVP and the guests (of course).

·          There was a Product owner: HR executive

·         and a ScrumMaster:  Most active member of the cultural team who is in my team and a guitarist also.

·         There was a development team: Members from HR department and members from cultural team.

I asked my teammates to plan this function in an agile way.
It started with a product backlog. The scrum team (HR executive as Product owner, Most active member of cultural team as ScrumMaster and members from HR department + members from cultural team as development team) started to put Product backlog items in a spread sheet.  The product backlog started taking shape. It was one sprint with number of tasks.

Product backlog items:

·         Prepare list of guests, hosts

·         Finalize venue

·         Finalize  name & logo to our annual function

·         Decide theme of the party

·         Decide dress code

·         Prepare List of eatables and drinks

·         Send invitations

·         Appreciation for employees for contribution to the society

·         Appreciation for Best employee(s)

·         Prepare list of dance performances – Solo /group

·         Prepare list of Plays/skits

·         Prepare list Songs – Solo /group

·         Other Surprise Events

Sprint Planning:

Team started sprint planning. There was only one sprint planned. 4 weeks time was to go. The shippable product was the ‘Annual Function’. Team started Daily Scrum meetings for 5 minutes after lunch to know what each member has done since yesterday. What they will do today and if anyone faced any impediments. Definition of Done was created for each items of the sprint.
User stories were broken down to tasks such as while preparing guest list, include the food preference.

Sprint Execution:

·         All team mates started their tasks and peers were doing the review. Regular feedbacks were being provided during the peer reviews.

Sprint Review:

·         As a shippable product, the Annual function was celebrated.

·         All stakeholders enjoyed it.

Retrospective:

·         START Doing – More such events.

·         STOP Doing – None

·         CONTINUE Doing – Encourage more participation to make the event more joyous.

Observations:

·         As a self organized team, all team mates were taking up the responsibilities actively and willingly.

·         Regular feedback during cultural activities was very helpful to prepare for the final event.

Mission ahead:
After the success of Annual function, here came the next vision from the CEO – ‘Clean and Green City’.
Product backlog is growing for this vision. Really BIG Mission ahead…..

‘I wish’..My vision!

Friends, today we will have a quick tour of a sprint. This journey will give us an overview of sprint taking place.

This is a fact that any product development starts with a ‘vision’- a clear vision. In scrum the vision need not to be created as a large multi page document. Only a small vision statement is sufficient.

The vision is further converted into stories (epics) in this initial phase. It is not necessary that scrum team will write these epics as scrum team may/may not have been formed at this stage.

This high level road map is created in the form of initial product backlog.

Once the vision gets approved by the stakeholders and scrum team has been formed, a release planning is done to establish the next logical step toward achieving the product goal. A definition of done (DoD) is also established. Product backlog grooming is one of the processes taken up during release planning. Release planning is done generally considering either fixed date (only those features are considered which could be delivered on planned date) or fixed scope (features will be decided first and based on that date is finalized). Team’s velocity is also taken into account.

The very next step is to conduct a story writing workshop. Epics are broken into stories and the stories are estimated in story points. Though Product owner is the primary person to write these stories, however if needed the complete scrum team helps him to write user stories.

A release generally consists of many sprints. Before each sprint a sprint planning is done. This planning takes 4 to 8 hours. The Product owner produces the prioritized product backlog consisting of the estimated PBIs with the defined acceptance criteria. Scrum team selects the stories and this makes the sprint backlog. Sprint backlog contains the break-up of user stories in tasks which is estimated in hours.

Here starts the sprint execution. Daily scrum (also known as daily scrum meeting – timeboxed for 15 minutes) is a part of sprint execution and as name indicates, occurs on daily basis.

When the sprint is about to finish, two most important activities are done. Sprint review and sprint retrospective. Sprint review (Timeboxed 120 minute max for 2 week sprint) is done by the stakeholders to see the completed work and ascertain that the sprint is executed as per the definition of done. Sometimes sprint review is also called sprint demo. However sprint review is more than a demo. It’s an ‘inspect’ activity.

After sprint review the last important activity Sprint retrospective is done (Timeboxed 60- 90 minutes max for 2 week sprint). In this activity the scrum team review all the scrum related activities performed. Team also envisions whether any activity needs improvement? And if yes, how to achieve that? Three important points discussed are:

• What we want to continue doing?
• What we should stop doing?
• What improvement should be done?

Outcome of every sprint is a shippable product increment. The subsequent sprint starts very next day once the current sprint finishes.

Any point needs more insight, please let me know. See you soon!

Kanban or kanban? Chocolates are decisive!

       One of my friend and colleague returned back from USA after a month long official visit. While we were going through the road-map of upcoming projects he had with him and the planning to apply suitable agile practices in these future projects, he cracked a joke on my previous posts on scrum saying, ‘Hey… in all your posts you do promise for at least one topic to be explored in future. This reminds me of television soaps which are generally left incomplete at such a point for the next episode that it becomes necessary to wait till next one.’ He also pointed my out for mentioning kanban as Kanban at places and for my promise of posting something about kanban.

Though I have yet not finished the initial planned posts on scrum but as my friend got me chocolates from USA, I am bound to start some ground up for kanban.

Kanban or kanban?

You must be thinking what sort of question is this? But he was correct* as the practice is called kanban.

* Moreover a few chocolates are still in my pocket so how can I argue on this. Readers, who have not got the chocolates, may follow any of these- kanban or Kanban.

Kanban is made of two Japanese words kan and ban. Kan means visual, and ban means card. kanban approach is based on the principles of Lean. The concept of Kanban came from Toyota, where it was invented as a scheduling system for just-in-time manufacturing in the Toyota Production System.

The most common problems faced during development:

• Wrong estimates
• Inability of delivering tasks on the committed date.
• Unclear priorities.
• Improper distribution of tasks.
• Tasks bombarded from everywhere.

Kanban the savior: Kanban is a very young yet popular methodology based on three principles:

• Visualize
• Limit work in process
• Manage flow

Visualize: First principle of kanban is to make information visible. This can be achieved using electronic kanban board or simply by creating sticky notes representing each task with it’s most current status on a board. The visualization of work-flow on the board becomes apparent to everyone in the team. At times there are a few tasks exists which are often not visible clearly but consumes a lot of time of the team.  Such tasks can easily be captured on the visual board so all team mates including the management also get aware of these tasks and hence can be planned in a better way.

Limit work in process: The second principle of kanban is to limit the WIP. In this principle we  establish a limit for items we will work on at one time. The benefit of taking up a fewer items being worked is that each item will be done more swiftly. Team will focus on the work which is

Manage flow: To manage the flow up-to finish of the task is the third principal of kanban.

This principle indicates to manage flow in a quick and uninterrupted way and keep the work-flow continuously improving.

Kanban methodology started with three principles however recently, David J. Anderson and a few fellows have extended the three basic principles to five properties and six practices. These are known as ‘Core practices’.

As the last chocolate I had, has been finished hence I am taking a short break now. We will continue with kanban in next few posts but before that I have to provide a quick and complete flow of Scrum which is still in pipeline. Most probable this weekend we will see that flow.

Any question on kanban? Please do not hesitate to ask. I will be replying as soon as possible.

Debts are not bad every time!

Hi Friends, technical debt during sprints is a less discussed but very important topic. Let us discuss this today.

What is a technical debt?

Technical debt refers to the incomplete work in the software systems. It also refers to the shortcuts we knowingly take.

Ward Cunningham (Cunningham 1992) was the first to explain about the concept of technical debt).

Generally there are three types of debts- naive debt, unavoidable debt, and deliberate debt.

Example of Naive debt:

• Incompetent design: This refers to a design that no longer makes sense due to various changes in business.
• Known defects: The known problems in the software that we haven’t yet removed considering these will not impact in immediate future.
• Insufficient testing: This refers to the known areas where more testing could have been done.

Example of Unavoidable debt:

• A third-party component we used in our product and the interfaces to that component evolved over time. 

Example of Deliberate debt:

• Such type of debt is taken to achieve an important short-term goal for example launching a time-sensitive product into the market. 

I remember a few months back my team took a deliberate technical debt by launching a product with USD as the only currency supported. This was because of the business decision of launching the product ahead of the competitors and we were aware that the focus market was of USA. Later we repaid it by providing the multi currency support. 

Today’s technical debt becomes a future work hence it requires a balanced technical and business discussion. Technical debt should be kept low enough to avoid future problems in product development. Also technical debt must be paid off time to time.

A good strategy is to utilize the time we get during sprints when there is some time left in which no next story can be fitted.

When it is not necessary to repay the technical debt?

To repay the technical is not necessay every time. Here are a few situations when technical debt not needs to be repaid.

When the product is nearing to end of life and to repay the debt is not a wise decision.

A product developed for a short life span.

How to repay technical debt?

• During the development activity, whenever a development team member finds a technical debt in the form of any problem, the team member should clean up the problem. 

• Technical debts which are more important should be repaid first. 

• Technical debts should be repaid incrementally time to instead of large late payments.

Technical debt is very important to understand and needs attention & timely repayment. If it is not repaid in time then it may become burden later and impacts on team's velocity.

We will discuss more on technical debt in later posts.

Kenneth S. Rubin (Essential Scrum) has explained about technical debt in a fantastic way. For a detailed explanation readers should refer that topic.

See you soon with more posts…Have a great time ahead!

Estimates are everywhere!

Today we will discuss further on estimating the PBIs.
During product development there are three most important questions which are asked at very beginning.

• Time: When will be the development completed?
• Scope: How many features will be delivered?
• Cost: What will be the cost?

This definitely requires estimating the size of features we plan to develop and the velocity of the team.
How we estimate PBIs?

We estimate Product backlog items (PBIs)/stories using relative sizes, not absolute sizes. There are two most common units of estimation- Story points and Ideal days. In these, ‘Story point’ has got more popularity.

Story points:

Story points are measured considering complexity and physical size of the PBI. PBI may be ‘complex but small’ OR ‘simple but large’ OR ‘simple and small’ OR ‘complex and large’. Ultimately we need to know the efforts required to develop that PBI. This is achieved by comparing stories and putting points on these.

For example, if we compare two stories and find that the latter will take 4 times the efforts than the first, then we estimate the points for second story as points provided to first story multiplied by 4.

A good strategy is to start with the smallest story and providing it point(s). The question is how to provide story point(s) to this story? Let’s assume that the smallest story is about to create a UI for Registration form and the next story which is about integration of a shopping cart in the application, when compared the latter takes 4 times the efforts which first story will take. If the first story is marked with 2 story points the next story will have 8 points (2 * 4).
Ideal days:

Estimation in ideal days is a technique of estimating PBIs and it represents the number of effort-days or man-days needed to complete a story. Ideal time should not be treated as elapsed time/calendar days. Ideal days are total effort in days and can span for many days as per the hours utilization per day.

What is velocity?

The amount of work completed in a sprint is known as team’s velocity. After each sprint the size of completed PBIs is added and that constitutes the velocity of the team. Partially completed PBIs

are not included in the velocity as they do not have any value for the product increment.

To know the number of sprints for the release, size of the release is divided by the team’s average velocity. So for example if the release has 500 points and the average velocity of a team is 50, then it will require 10 sprints for that release.

Planning Poker

Planning Poker is a technique for sizing PBIs. Planning Poker was first described by James Grenning (Grenning 2002) and popularized by Mike Cohn (Cohn 2006).

The game begins…

The Product owner describes the PBIs and the ScrumMaster closely monitors, guides and motivates the team to participate in Poker planning.

Each development team member is provided with a set of Planning Poker cards for this game.

The product owner selects a PBI and reads the item to the team. Development team members discuss the item and ask questions to the product owner if any clarity needed on that PBI. Each member of development team selects a card representing his estimate without disclosing it to other team mates.

Once each estimator has made a private selection, all estimates are simultaneously shown to all estimators. If everyone selects the same card then it becomes the PBI estimate. If the estimates are not the same, the team members discuss and repeat the same until consensus is reached.

In no case average of the estimates is agreed as an estimate for any PBI.

This is how we estimate the tasks and velocity. If more clarity is needed on any point, please let me know. I will try to reply as soon as possible…

User stories continued...

In continuation of previous post…

Overview of User Stories:

Traditionally user stories are hand written on paper cards. Some times we use colored sticky to write story and place them over a wide board where each team member can easily view.  In addition to it there are many tools to help write and manage user stories. Rally and JIRA agile are a few I generally prefer.

It is not required to write all details as stories. Instead the development team and the customer discuss these details and make a few annotations on a story card based on the discussions.

Generally a story writing workshop is conducted to write the stories in the initial phase of starting the project, but this is not a strict rule. Stories can be written at any time throughout the project. Though the Product owner is responsible for writing the stories but the whole scrum team including domain experts do the brainstorming and facilitate Product owner during the story writing.

Each story is estimated in story points by the development team. Story points indicate the size and complexity of the story relative to other stories. These story points are very useful to determine the velocity of the team. We will discuss velocity in future. In short we can say that velocity is the number of story points the team think will be complete per sprint.

Acceptance Tests:

Acceptance testing is the process of verifying that stories were developed such that each works exactly the way the customer team expected it to work. The back of a story card holds reminders about how to test the story. These can be added of removed any time.

These tests capture the expectations of the stake holders that should be handled by the system.

User Roles:

It is very important to understand that there may be different users of the product/software. Every user has different perspectives and goals towards the product. This is the reason that before writing stories different user roles should be taken into consideration. For example in a B2B or B2C product there may be internal customers, external customers, admin group etc. Thus this will have significant impact on user stories. A very fantastic way to achieve the user role is to have persona. Think for it…and compare with avatars. I truly look forward to your views on it.

Techniques to write stories:

There are many techniques and a few are as below.

• Story-Writing workshops

• User interviews

• Questionnaires

• Observation

Estimating user stories:

User stories can be estimated in story points. Planning Poker is one of the techniques first described by James Grenning (Grenning 2002) and then popularized by Mike Cohn (Cohn 2006) is my favorite. We will see this technique in near future. For the fast and furious scrum followers check out your mobile devices (I used the android play store), you will find many fascinating tools free of cost for planning pokers.

User stories are further broken into tasks. Tasks help us to develop in a calculated way.

There is an acronym for creating effective tasks: SMART’.

S – Specific

M – Measurable

A – Achievable

R – Relevant

T – Time-boxed

Caution: Estimation is the part which is most concerning to each stakeholder. Let us discuss it further. I expect a few questions from all reviewers of this post. Till then ‘Have a great day ahead’.