Agile at Work: Planning with Agile User Stories -Creating your project charter, Using relative estimation

Creating a project charter is a great  way to understand the project direction as a whole. But there are always some things an organization will want to understand to deliver a successful project charter, and ultimately, the project itself. Charters should contain criteria for success and an overall mission, with an integral component being that of adapting to bring forward value and not trying to predict value before the project beings. Project teams need to make sure they know the difference between the vision of the project being met and team success. Project charters within the Agile framework should be something that is agreed upon and not a plan that needs to be carried out. Every component of the project should be listed by what each group wants to be delivered, and the customer should create a formal charter to push the team in a beginning direction.

With charters, we need to understand that this does not mean things will not be changing, but instead, it helps the team brainstorm and jot down ideas at the inception of the project. In order to close a project, these project charters become extremely important to execute. The only way for a customer and team to fully check all the boxes that consider a project fully delivered is to have the agile team create a retrospective meeting where members can take down all lessons that have been learned from the agile process. Proper and successful project charters should be roughly one page of content with only three major sections: success criteria, vision, and the project mission.

When using relative estimation, teams will use time measurements such as hours, days, and weeks. This measurement can often become more of a focus than an ability the team may have with understanding what work is to be done, and as a result, team members will usually estimate using ranges of time. These estimations are not made to be accounted for exactly, but instead, give means to create a dialogue about what is needed to deliver stories. There are many reasons agile teams use this type of estimating, but the main two are: a false satisfaction of precision, and it keeps the agile team from blurring assessments from needs. These relative estimates gives the team the ability to get right to work and prevents members from losing time discussing how long any specific task might take.

Works Cited

"Agile at Work: Planning with Agile User Stories." www.lynda.com/Business-Skills-tutorials/		Agile-Work-Planning-Agile-User-Stories/175074-2.html. Accessed 10 Nov. 2017.

Image link: https://usercontent2.hubstatic.com/13342829_f496.jpg