search back preload
Unified Blog
Killing the Sprint?
PDF
Print
E-mail
Written by Lisbeth Cardoso   
Friday, 28 September 2012 16:24


KILLED

Can management or the team cancel a Sprint before its conclusion? The answer is yes. It rarely happens though, due to the short duration of Sprints, but it may be plausible and definitely possible.

Management can abruptly end a Sprint if its goal becomes obsolete, market conditions and/ or technological requirements change, or the company as a whole looks for new directions.

Teams can also decide to terminate a Sprint if they run into a major roadblock or dead-end,  or realize mid-way through the Sprint that its goal either won’t be or was already achieved. Team’s authority to cancel a Sprint is quite important because it will give them absolute control of their performance.

In conclusion, a Sprint should be terminated either by management or the team when it no longer makes sense.

                                                                       

Last Updated on Friday, 28 September 2012 16:39
 
Sprint Mechanics
PDF
Print
E-mail
Written by Lisbeth Cardoso   
Friday, 28 September 2012 15:53

                    SPRINT

How does a Sprint behave?

Sprints usually last from 2 to 4 weeks. During each Sprint, the team has absolute authority to work as they decide to. Therefore, team members can expend days or hours collecting information, studying, interviewing consultants, or doing research. They can participate in long design sessions, or hold meetings whenever they need them. Team members can work as few or as many hours as they want to. Their goal is just to produce the required product increment at the end of the Sprint.

The team members have the power to modify the functionality of the Sprint by increasing or decreasing its scope or depth, as long as it accomplishes the Sprint goal. At the Sprint Review meeting, the delivered functionality is demonstrated and discussed. If there is any unimplemented functionality, it will become part of the next Sprint’s Product Backlog.

The Daily Scrum meetings and the Sprint Backlog are the team’s two mandatory working tools. Each member must attend to the Daily Scrum meetings and provide an active status report. The Sprint Backlog must always remain up-to-date and as accurate as possible.

The team’s ability to work as a unit, its member’ skills, the work to be performed, and the tools and standards provided to it determine how much work will be accomplished by the team.

At the end of the Sprint, the team will have to deliver a product increment that converges to or excels Sprint’s goal.

Last Updated on Friday, 28 September 2012 16:37
 
New Release
PDF
Print
E-mail
Written by Administrator   
Thursday, 27 September 2012 01:13

RN.png

IMPORTANT! What’s New on this latest version of ISU?

 

vTask Manager

  • Scrum Editor screen added.
  • Estimate Delta Percentage column added.
  • Link button added.
  • Send multiple tasks to timesheets screen added.
  • Release Notes screen added.
  • See Documents functionality added.

vTimesheet Manager

  • Submit date functionality fixed.

vProject Manager

  • User Story Track added.
  • BurnDown Chart added.
  • Attach File functionality added.

vSQA

  • Export List To Excel functionality added.
  • Create New Plan and cases based on the current plan functionality added.
  • Execute Current Plan functionality added.
  • Edit Latest Executed Cases functionality added.
  • Edit Original Cases functionality added.
  • Create Cases Based On Tasks functionality added.

vApplication Manager

  • Status field added.

vMember Profiles

  • Visual Enhancements.


General enhancements: All grids maintain the same look and feel.

                                                        Release Notes popup added.


Last Updated on Thursday, 27 September 2012 16:26
 
Sprint Planning Meeting
PDF
Print
E-mail
Written by Lisbeth Cardoso   
Wednesday, 19 September 2012 17:30

At the Sprint Planning Meeting the Scrum team, the Scrum Master, the Product Owner, management, and users get together to determine the next Sprint goal and functionalities.

Actually, the Sprint Planning meeting bifurcates in two meetings. At the first meeting, the team gets together with management, the Product Owner, and users to decide what portion of the Product Backlog will be built during the next Sprint. At the second meeting, the team encounters with the Scrum Master to determine how it’s going to transform this portion of Product Backlog into product increment.

At the first meeting, taking into consideration the obtained results in the previous Sprint, the Product Owner presents the top priority Product Backlog to treat in the next Sprint. Then the team negotiates with the Product Owner, management and clients what portion it believes it can develop during the next Sprint.

At the second meeting, it is the team the one who decides what set of tasks will have to perform and in which order. This set of tasks is called the Sprint Backlog. Each task should have enough detailed information and take between 4 to 16 hours to complete.

Sometimes, the team might have to create designs or define the architecture before delineating the rest of the tasks. In this case, the initial investigation, design and architecture must be defined as much as possible. Once they are completed, the team can move forward to coding.

The Sprint Backlog is modified throughout the entire Sprint by the team. Each team member can determine if more or less of his or her original tasks are needed, if there are some unnecessary tasks, if a particular task will take more or less time to be completed.

At first, teams usually under-commit. Once they get more familiar with the Scrum approach, they become better at Sprint planning and commit to more work.

Last Updated on Wednesday, 19 September 2012 18:57
 
Learning to Dance to a Different Tune
PDF
Print
E-mail
Written by Lisbeth Cardoso   
Friday, 07 September 2012 18:57

In 1994, Bill Gates, then CEO and founder of Microsoft Corporation, told his closest team and advisors that the internet was not a money maker for their company. In fact, he would leave it to other parties to fight over a limited market. Within 6 months the entire direction at Microsoft changed. Not only were they going to find a market in the cyber world but their goal was to dominate.

Mozilla at the time was the leading internet browser. Within 2 years, the Internet Explorer offered by Microsoft pushed Mozilla out of the lead position. Today, the market is still changing with the Mozilla Firefox project, an open source operating system and explorer ecosystem in one. Will Microsoft respond to this new initiative? Most likely is the obvious answer.

An organizations ability to change and respond to surrounding threats and opportunities is really based on the ability of the individuals who work in the company to respond to change. The individual’s ability to change can be summed up by a change management paradigm known as ADKAR. ADKAR is an acronym for Awareness, Desire, Knowledge, Ability and Reinforcement.

One of the best books that discuss the ADKAR approach is ‘ADKAR: A model for Change in Business Government and Our Community’ by Jeffrey M. Hiatt  On the consulting side, Prosci  is an independent research company in the field of change management that uses the ADKAR approach to coach individuals and organizations.

As IT professionals change is something we face every day, understanding the nature of change as individuals is as important as understanding the business requirements for a new application.  Assessing one’s client or one’s self in the world of IT may provide a greater understanding and insight into some of the road blocks that are encountered in our daily lives and provide an opportunity to overcome these challenges.

 

Gil Darnley, PMP, CMA

Information Technology Director – Business Development

 
<< Start < Prev 1 2 3 4 5 6 7 Next > End >>

RSS-header

RSS-bottom